Tom Tromey [Tue, 22 Feb 2022 19:02:10 +0000 (12:02 -0700)]
Fix bug in Ada attributes lexing
The Ada lexer allows whitespace between the apostrophe and the
attribute text, but processAttribute does not handle this. This patch
fixes the problem and introduces a regression test.
Tom Tromey [Tue, 22 Feb 2022 18:05:41 +0000 (11:05 -0700)]
Remove null sentinel from 'attributes'
In a subsequent patch, it's handy if the 'attributes' array in
ada-lex.l does not have a NULL sentinel at the end. In C++, this is
easy to avoid.
Tom Tromey [Tue, 15 Mar 2022 15:03:14 +0000 (09:03 -0600)]
Handle ghost entities in symbol lookup
Normally, SPARK ghost entities are removed from the executable.
However, with -gnata, they will be preserved. In this situation, it's
handy to be able to inspect them. This patch allows this by removing
the "___ghost_" prefix in the appropriate places.
Simon Marchi [Mon, 28 Mar 2022 22:17:17 +0000 (18:17 -0400)]
gdb: rename start_symtab/end_symtab to start_compunit_symtab/end_compunit_symtab
It's a bit confusing because we have both "compunit_symtab" and "symtab"
types, and many methods and functions containing "start_symtab" or
"end_symtab", which actually deal with compunit_symtabs. I believe this
comes from the time before compunit_symtab was introduced, where
symtab did the job of both.
Rename everything I found containing start_symtab or end_symtab to use
start_compunit_symtab or end_compunit_symtab.
Change-Id: If3849b156f6433640173085ad479b6a0b085ade2
Simon Marchi [Mon, 28 Mar 2022 22:17:16 +0000 (18:17 -0400)]
gdb: remove some unused buildsym-legacy functions
Pretty much self-explanatory.
Change-Id: I5b658d017cd891ecdd1df61075eacb0f44316935
Fangrui Song [Mon, 4 Apr 2022 15:43:50 +0000 (08:43 -0700)]
gas: copy st_size only if unset
For
```
.size foo1, 1
foo1:
.set bar1, foo1
.size bar1, 2
.size bar2, 2
.set bar2, foo1
.set bar3, foo2
.size bar3, 2
.size bar4, 2
.set bar4, foo2
.size foo2, 1
foo2:
```
bar1's size is 2 while bar2, bar3, bar4's is 1. The behavior of bar1 makes sense
(generally directives on the new symbol should win) and is relied upon by glibc
stdio-common/errlist.c:
```
.hidden _sys_errlist_internal
.globl _sys_errlist_internal
.type _sys_errlist_internal, @object
.size _sys_errlist_internal, 1072
_sys_errlist_internal:
.globl __GLIBC_2_1_sys_errlist
.set __GLIBC_2_1_sys_errlist, _sys_errlist_internal
.type __GLIBC_2_1_sys_errlist, %object
.size __GLIBC_2_1_sys_errlist, 125 * (64 / 8)
// glibc expects that .size __GLIBC_2_1_sys_errlist, 125 * (64 / 8) wins.
```
The behavior of bar2/bar3/bar4 seems brittle. To avoid the reordering of the two
code blocks which will result in the bar3 situation, glibc compiles errlist.c
with gcc -fno-toplevel-reorder (previously -fno-unit-at-a-time).
To fix the inconsistency and improve robustness, make bar2/bar3/bar4 match bar1,
removing the directive order sensitivity.
There is a pity that `.size dest, 0` is indistinguishable from the case where
dest is unset, but the compromise seems fine.
PR gas/29012
* config/obj-elf.c (elf_copy_symbol_attributes): don't copy if src's size
has been set.
* testsuite/gas/elf/elf.exp: New test.
* testsuite/gas/elf/size.d: New file.
* testsuite/gas/elf/size.s: Likewise.
Andrew Burgess [Mon, 4 Apr 2022 12:41:49 +0000 (13:41 +0100)]
gdb: remove use of vfprintf_filtered
Commit:
commit
60a3da00bd5407f07d64dff82a4dae98230dfaac
Date: Sat Jan 22 11:38:18 2022 +0000
objdump/opcodes: add syntax highlighting to disassembler output
Introduced a new use of vfprintf_filtered, which has been deprecated.
This commit replaces this with gdb_vprintf instead.
Andrew Burgess [Sat, 5 Feb 2022 11:25:14 +0000 (11:25 +0000)]
opcodes/i386: partially implement disassembler style support
This commit adds partial support for disassembler styling in the i386
disassembler.
The i386 disassembler collects the instruction arguments into an array
of strings, and then loops over the array printing the arguments out
later on. The problem is that by the time we print the arguments out
it's not obvious what the type of each argument is.
Obviously this can be fixed, but I'd like to not do that as part of
this commit, rather, I'd prefer to keep this commit as small as
possible to get the basic infrastructure in place, then we can improve
on this, to add additional styling, in later commits.
For now then, I think this commit should correctly style mnemonics,
some immediates, and comments. Everything else will be printed as
plain text, which will include most instruction arguments, unless the
argument is printed as a symbol, by calling the print_address_func
callback.
Ignoring colours, there should be no other user visible changes in the
output of the disassembler in either objdump or gdb.
opcodes/ChangeLog:
* disassembler.c (disassemble_init_for_target): Set
created_styled_output for i386 based targets.
* i386-dis.c: Changed throughout to use fprintf_styled_func
instead of fprintf_func.
Andrew Burgess [Sat, 5 Feb 2022 11:25:24 +0000 (11:25 +0000)]
opcodes/riscv: implement style support in the disassembler
Update the RISC-V disassembler to supply style information. This
allows objdump to apply syntax highlighting to the disassembler
output (when the appropriate command line flag is used).
Ignoring colours, there should be no other user visible changes in the
output of the disassembler in either objdump or gdb.
opcodes/ChangeLog:
* disassembler.c (disassemble_init_for_target): Set
created_styled_output for riscv.
* riscv-dis.c: Changed throughout to use fprintf_styled_func
instead of fprintf_func.
Andrew Burgess [Sat, 22 Jan 2022 11:38:18 +0000 (11:38 +0000)]
objdump/opcodes: add syntax highlighting to disassembler output
This commit adds the _option_ of having disassembler output syntax
highlighted in objdump. This option is _off_ by default. The new
command line options are:
--disassembler-color=off # The default.
--disassembler-color=color
--disassembler-color=extended-color
I have implemented two colour modes, using the same option names as we
use of --visualize-jumps, a basic 8-color mode ("color"), and an
extended 8bit color mode ("extended-color").
The syntax highlighting requires that each targets disassembler be
updated; each time the disassembler produces some output we now pass
through an additional parameter indicating what style should be
applied to the text.
As updating all target disassemblers is a large task, the old API is
maintained. And so, a user of the disassembler (i.e. objdump, gdb)
must provide two functions, the current non-styled print function, and
a new, styled print function.
I don't currently have a plan for converting every single target
disassembler, my hope is that interested folk will update the
disassemblers they are interested in. But it is possible some might
never get updated.
In this initial series I intend to convert the RISC-V disassembler
completely, and also do a partial conversion of the x86 disassembler.
Hopefully having the x86 disassembler at least partial converted will
allow more people to try this out easily and provide feedback.
In this commit I have focused on objdump. The changes to GDB at this
point are the bare minimum required to get things compiling, GDB makes
no use of the styling information to provide any colors, that will
come later, if this commit is accepted.
This first commit in the series doesn't convert any target
disassemblers at all (the next two commits will update some targets),
so after this commit, the only color you will see in the disassembler
output, is that produced from objdump itself, e.g. from
objdump_print_addr_with_sym, where we print an address and a symbol
name, these are now printed with styling information, and so will have
colors applied (if the option is on).
Finally, my ability to pick "good" colors is ... well, terrible. I'm
in no way committed to the colors I've picked here, so I encourage
people to suggest new colors, or wait for this commit to land, and
then patch the choice of colors.
I do have an idea about using possibly an environment variable to
allow the objdump colors to be customised, but I haven't done anything
like that in this commit, the color choices are just fixed in the code
for now.
binutils/ChangeLog:
* NEWS: Mention new feature.
* doc/binutils.texi (objdump): Describe --disassembler-color
option.
* objdump.c (disassembler_color): New global.
(disassembler_extended_color): Likewise.
(disassembler_in_comment): Likewise.
(usage): Mention --disassembler-color option.
(long_options): Add --disassembler-color option.
(objdump_print_value): Use fprintf_styled_func instead of
fprintf_func.
(objdump_print_symname): Likewise.
(objdump_print_addr_with_sym): Likewise.
(objdump_color_for_disassembler_style): New function.
(objdump_styled_sprintf): New function.
(fprintf_styled): New function.
(disassemble_jumps): Use disassemble_set_printf, and reset
disassembler_in_comment.
(null_styled_print): New function.
(disassemble_bytes): Use disassemble_set_printf, and reset
disassembler_in_comment.
(disassemble_data): Update init_disassemble_info call.
(main): Handle --disassembler-color option.
include/ChangeLog:
* dis-asm.h (enum disassembler_style): New enum.
(struct disassemble_info): Add fprintf_styled_func field, and
created_styled_output field.
(disassemble_set_printf): Declare.
(init_disassemble_info): Add additional parameter.
(INIT_DISASSEMBLE_INFO): Add additional parameter.
opcodes/ChangeLog:
* dis-init.c (init_disassemble_info): Take extra parameter,
initialize the new fprintf_styled_func and created_styled_output
fields.
* disassembler.c (disassemble_set_printf): New function definition.
Tom Tromey [Fri, 1 Apr 2022 20:29:35 +0000 (14:29 -0600)]
Remove more Python 2 code
I found another more place that still had a workaround for Python 2.
This patch removes it.
Tom de Vries [Mon, 4 Apr 2022 08:56:51 +0000 (10:56 +0200)]
[gdb/testsuite] Fix KPASS in gdb.ada/arrayptr.exp
On openSUSE Leap 15.3 I run into:
...
KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all \
(PRMS minimal encodings)
KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3) \
(PRMS minimal encodings)
KPASS: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr.all(3) \
(PRMS minimal encodings)
...
The test-case KFAILs some tests. However, the analysis in the corresponding
PR talks of a compiler problem, so it should use XFAILs instead.
The KFAILs are setup for pre-gcc-12, but apparantly the fix has been
backported to system compiler 7.5.0, hence the KPASS.
Fix this by:
- using an XFAIL instead of a KFAIL
- matching the specific gdb output that corresponds to the XFAILs
(reproduced on Fedora 34).
Tested on x86_64-linux, specifically openSUSE Leap 15.3 and Fedora 34.
GDB Administrator [Mon, 4 Apr 2022 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in
rupothar [Thu, 17 Mar 2022 18:56:23 +0000 (18:56 +0000)]
gdb: add support for Fortran's ASSUMED RANK arrays
This patch adds a new dynamic property DYN_PROP_RANK, this property is
read from the DW_AT_rank attribute and stored within the type just
like other dynamic properties.
As arrays with dynamic ranks make use of a single
DW_TAG_generic_subrange to represent all ranks of the array, support
for this tag has been added to dwarf2/read.c.
The final piece of this puzzle is to add support in gdbtypes.c so that
we can resolve an array type with dynamic rank. To do this the
existing resolve_dynamic_array_or_string function is split into two,
there's a new resolve_dynamic_array_or_string_1 core that is
responsible for resolving each rank of the array, while the now outer
resolve_dynamic_array_or_string is responsible for figuring out the
array rank (which might require resolving a dynamic property) and then
calling the inner core.
The resolve_dynamic_range function now takes a rank, which is passed
on to the dwarf expression evaluator. This rank will only be used in
the case where the array itself has dynamic rank, but we now pass the
rank in all cases, this should be harmless if the rank is not needed.
The only small nit is that resolve_dynamic_type_internal actually
handles resolving dynamic ranges itself, which now obviously requires
us to pass a rank value. But what rank value to use? In the end I
just passed '1' through here as a sane default, my thinking is that if
we are in resolve_dynamic_type_internal to resolve a range, then the
range isn't part of an array with dynamic rank, and so the range
should actually be using the rank value at all.
An alternative approach would be to make the rank value a
gdb::optional, however, this ends up adding a bunch of complexity to
the code (e.g. having to conditionally build the array to pass to
dwarf2_evaluate_property, and handling the 'rank - 1' in
resolve_dynamic_array_or_string_1) so I haven't done that, but could,
if people think that would be a better approach.
Finally, support for assumed rank arrays was only fixed very recently
in gcc, so you'll need the latest gcc in order to run the tests for
this.
Here's an example test program:
PROGRAM arank
REAL :: a1(10)
CALL sub1(a1)
CONTAINS
SUBROUTINE sub1(a)
REAL :: a(..)
PRINT *, RANK(a)
END SUBROUTINE sub1
END PROGRAM arank
Compiler Version:
gcc (GCC) 12.0.0
20211122 (experimental)
Compilation command:
gfortran assumedrank.f90 -gdwarf-5 -o assumedrank
Without Patch:
gdb -q assumedrank
Reading symbols from assumedrank...
(gdb) break sub1
Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
(gdb) run
Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank
Breakpoint 1, arank::sub1 (a=<unknown type in /home/rupesh/STAGING-BUILD-2787
/bin/assumedrank, CU 0x0, DIE 0xd5>) at assumedrank.f90:10
10 PRINT *, RANK(a)
(gdb) print RANK(a)
'a' has unknown type; cast it to its declared type
With patch:
gdb -q assumedrank
Reading symbols from assumedrank...
(gdb) break sub1
Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
(gdb) run
Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank
Breakpoint 1, arank::sub1 (a=...) at assumedrank.f90:10
10 PRINT *, RANK(a)
(gdb) print RANK(a)
$1 = 1
(gdb) ptype a
type = real(kind=4) (10)
(gdb)
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Andrew Burgess [Wed, 16 Mar 2022 17:32:25 +0000 (17:32 +0000)]
gdb/dwarf: pass an array of values to the dwarf evaluator
When we need to evaluate a DWARF expression in order to resolve some
dynamic property of a type we call the dwarf2_evaluate_property
function, which is declared in gdb/dwarf/loc.h and defined in
gdb/dwarf/loc.c.
Currently, this function takes (amongst other things) an argument of
type property_addr_info called addr_stack and a boolean called
push_initial_value. When push_initial_value then the top value of
addr_stack is pushed onto the dwarf expression evaluation stack before
the expression is evaluated.
So far this has worked fine, as the only two cases we needed to handle
are the case the DWARF expression doesn't require the object
address (what the top of addr_stack represents), and the case where
the DWARF expression does require the address.
In the next commit this is going to change. As we add support for
Fortran assumed rank arrays, we need to start resolving the dynamic
properties of arrays. To do this, we need to push the array rank onto
the dwarf expression evaluation stack before the expression is
evaluated.
This commit is a refactoring commit aimed at making it easier to
support Fortran assumed rank arrays. Instead of passing a boolean,
and using this to decide if we should push the object address or not,
we instead pass an array (view) of values that should be pushed to the
dwarf expression evaluation stack.
In the couple of places where we previously passed push_initial_value
as true (mostly this was defaulting to false), we now have to pass the
address from the addr_stack as an item in the array view.
In the next commit, when we want to handle passing the array rank,
this will easily be supported too.
There should be no user visible changes after this commit.
Andrew Burgess [Wed, 16 Mar 2022 15:32:50 +0000 (15:32 +0000)]
gdb: small simplification in dwarf2_locexpr_baton_eval
While examining the dwarf expression evaluator, I noticed that in
dwarf2_locexpr_baton_eval, whenever push_initial_value is true, the
addr_stack will never be nullptr.
This allows for a small cleanup, replacing an if/then/else with an
assertion.
There should be no user visible changes after this commit.
Andrew Burgess [Sun, 3 Apr 2022 15:48:09 +0000 (16:48 +0100)]
gdb/testsuite: resolve some duplicate test names in gdb.base
This commit resolves all the duplicate test names that I see in the
script:
gdb.base/attach-pie-misread.exp
The duplicate names all come from a second call to
build_executable_own_libs, so in this commit I've places the second
call inside a with_test_prefix block.
While I was making this change I've also modified the value being
passed as the testname for the second build_executable_own_libs call.
Previously we used ${test}, however, I think this was likely a
mistake, the 'test' variable is setup for the previous test. I
suspect that ${testfile} is a better choice - especially now we have a
testname prefix.
As the testname is only used (after various calls) from within
build_executable_from_specs should the build fail, I don't think this
change really makes much difference though.
There should be no change in what is tested after this commit.
Andrew Burgess [Sun, 3 Apr 2022 15:36:48 +0000 (16:36 +0100)]
gdb/testsuite: resolve a duplicate test name in a gdb.mi test
Solve two duplicate test names in the test script:
gdb.mi/mi-catch-cpp-exceptions.exp
by moving the call to restart_for_test inside the with_test_prefix
block. There should be no difference in what is tested after this
commit.
Andrew Burgess [Wed, 23 Mar 2022 10:29:49 +0000 (10:29 +0000)]
gdb/Makefile.in: move ALLDEPFILES earlier in Makefile.in
If I do 'make tags' in the gdb build directory, the tags target does
complete, but I see these warnings:
../../src/gdb/arm.c: No such file or directory
../../src/gdb/arm-get-next-pcs.c: No such file or directory
../../src/gdb/arm-linux.c: No such file or directory
The reason for this is the ordering of build rules and make variables
in gdb/Makefile.in, specifically, the placement of the tags related
rules, and the ALLDEPFILES variable. The ordering is like this:
TAGFILES_NO_SRCDIR = .... $(ALLDEPFILES) ....
TAGS: $(TAGFILES_NO_SRCDIR) ....
# Recipe uses $(TAGFILES_NO_SRCDIR)
tags: TAGS
ALLDEPFILES = .....
When the TAGS rule is parsed TAGFILES_NO_SRCDIR is expanded, which
then expands ALLDEPFILES, which, at that point in the Makefile is
undefined, and so expands to the empty string. As a result TAGS does
not depend on any file listed in ALLDEPFILES.
However, when the TAGS recipe is invoked ALLDEPFILES is now defined.
As a result, all the files in ALLDEPFILES are passed to the etags
program.
The ALLDEPFILES references three files, arm.c, arm-get-next-pcs.c, and
arm-linux.c, which are actually in the gdb/arch/ directory, but, in
ALLDEPFILES these files don't include the arch/ prefix. As a result,
the etags program ends up looking for these files in the wrong
location.
As ALLDEPFILES is only used by the TAGS rule, this mistake was not
previously noticed (the TAGS rule itself was broken until a recent
commit).
In this commit I make two changes, first, I move ALLDEPFILES to be
defined before TAGFILES_NO_SRCDIR, this means that the TAGS rule will
depend on all the files in ALLDEPFILES. With this change the TAGS
rule now breaks complaining that there's no rule to build the 3 files
mentioned above.
Next, I have added all *.c files in gdb/arch/ to ALLDEPFILES,
including their arch/ prefix, and removed the incorrect (missing arch/
prefix) references.
With these two changes the TAGS (or tags if you prefer) target now
builds without any errors or warnings.
Reuben Thomas [Tue, 22 Mar 2022 22:10:17 +0000 (22:10 +0000)]
gdb/Makefile.in: fix 'make tags' build target
The gdb_select.h file was moved to the gdbsupport directory long ago,
but a reference was accident left in gdb/Makefile.in (in the
HFILES_NO_SRCDIR variable), this commit removes that reference.
Before this commit, if I use 'make tags' here's what I see:
$ make tags
make: *** No rule to make target 'gdb_select.h', needed by 'TAGS'. Stop.
After this commit 'make tags' completes, but I still see these
warnings:
../../src/gdb/arm.c: No such file or directory
../../src/gdb/arm-get-next-pcs.c: No such file or directory
../../src/gdb/arm-linux.c: No such file or directory
These are caused by a separate issue, and will be addressed in the
next commit.
Andrew Burgess [Wed, 23 Mar 2022 10:02:49 +0000 (10:02 +0000)]
gdb/Makefile.in: remove SOURCES variable
The SOURCES variable was added to gdb/Makefile.in as part of commit:
commit
fb40c20903110ed8af9701ce7c2635abd3770d52
Date: Wed Feb 23 00:25:43 2000 +0000
Add mi/ and testsuite/gdb.mi/ subdirectories.
But as far as I can tell was not used at the time it was added, and is
not used today.
Lets remove it.
Andrew Burgess [Tue, 1 Feb 2022 14:59:11 +0000 (14:59 +0000)]
gdb/tui: fair split of delta after a resize
Currently, in master gdb, when a tui window is changed in size, the
screen delta is mostly just added to the next available window. We
do take care to respect the min/max size, but in most cases, these
limits are just "the terminal size", and so, we end up placing the
whole delta on the next window.
Consider these steps in an 80 column, 24 line terminal:
(gdb) tui enable
(gdb) layout src
(gdb) layout split
(gdb) info win
Name Lines Columns Focus
src 8 80 (has focus)
asm 8 80
status 1 80
cmd 8 80
(gdb) winheight cmd +2
(gdb) info win
Name Lines Columns Focus
src 6 80 (has focus)
asm 8 80
status 1 80
cmd 10 80
Notice that initially, the windows were balanced, 8 lines each for the
major windows. Then, when the cmd window was adjusted, the extra two
lines were given to the asm window.
I think it would be nicer if the delta was spread more evenly over the
available windows. In the example above, after the adjustment the
layout now looks like:
(gdb) info win
Name Lines Columns Focus
src 7 80 (has focus)
asm 7 80
status 1 80
cmd 10 80
This is achieved within tui_layout_split::set_size, by just handing
out the delta in increments of 1 to each window (except for the window
the user adjusted), until there's no more delta left. Of course, we
continue to respect the min/max window sizes.
Andrew Burgess [Tue, 1 Feb 2022 14:09:26 +0000 (14:09 +0000)]
gdb/tui: relax restrictions on window max height and width
This commit removes some arbitrary adjustments made in
tui_cmd_window::max_height, tui_win_info::max_height, and
tui_win_info::max_width.
These member functions all subtract some constant from the theoretical
maximum height or width. I've looked back through the history a
little and can see no real reason why these adjustments should be
needed, with these adjustments removed all the existing tui tests
still pass.
However, retaining these restrictions causes some bugs, consider:
(gdb) tui new-layout hsrc {-horizontal src 1 cmd 1} 1
When this layout is selected with current master, gdb will leave a 4
line gap at the bottom of the terminal.
The problem is that the maximum height is restricted, for the cmd
window, to 4 less than the terminal height.
By removing this restriction gdb is able to size the windows to the
complete terminal height, and the layout is done correctly.
This 4 line restriction is also what prevents this layout from working
correctly:
(gdb) tui new-layout conly cmd 1
Previously, this layout would present a cmd window only, but there
would be a 4 line gap at the bottom of the terminal. This issue was
mentioned in an earlier commit in this series (when a different bug
was fixed), but with this commit, the above layout now correctly fills
the terminal. The associated test is updated.
After removing the adjustment in tui_cmd_window::max_height, the
implementation is now the same as the implementation in the parent
class tui_win_info, so I've completely removed the max_height call
from tui_cmd_window.
Andrew Burgess [Tue, 1 Feb 2022 14:24:15 +0000 (14:24 +0000)]
gdb/testsuite: some additional tests in gdb.tui/scroll.exp
This commit just adds an extra check of the src window size prior to
sending all the commands to gdb. We also set the cmd window height to
its existing height, this (obviously) shouldn't change the window
layout, which we check.
My main motivation was adding the initial window layout check, the
winheight and recheck are just extras. All of these test pass both
before and after this commit.
Andrew Burgess [Tue, 1 Feb 2022 14:02:19 +0000 (14:02 +0000)]
gdb/tui: support placing the cmd window into a horizontal layout
This commit allows the user to place the cmd window within horizontal
tui layouts. Consider this set of steps, carried out in an 80 columns
by 24 lines terminal, using current master gdb:
(gdb) tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1
(gdb) tui layout hsrc
What you end up with is a full width cmd window with the status bar
beneath. Where's the src window gone? We then try:
(gdb) info win
Name Lines Columns Focus
src 23 3 (has focus)
cmd 23 80
status 1 80
(gdb)
Something weird has gone on, gdb has overlapped the cmd window with
the src window. If we trigger the src window to redraw is content,
for example, 'list main', then we see corruption in the cmd window as
the src window overwrites it.
So, what's going on?
The problem is some code in tui_layout_split::apply, in tui-layout.c.
Within 'Step 1', there is a loop that calculates the min/max window
sizes for all windows within a tui_layout_split. However, there's a
special case for the cmd window.
This special case is trying to have the cmd window retain its current
size when a layout is re-applied, or a new layout is applied. This
makes sense, consider moving from the 'src' layout to the 'asm'
layout, this looks something like this (status window removed):
.-------. .-------.
| src | | asm |
|-------| ====> |-------|
| cmd | | cmd |
'-------' '-------'
If the user has gone to the effort of adjusting the cmd window size,
then, the thinking goes, we shouldn't reset the cmd window size when
switching layouts like this.
The problem though, is that when we do a switch more like this:
.-----------. .-----------.
| src | | | |
|-----------| ====> | asm | cmd |
| cmd | | | |
'-----------' '-----------'
Now retaining the cmd window width makes no sense; the new layout has
a completely different placement for the cmd window, instead of sizing
by height, we're now sizing by width. The existing code doesn't
understand this though, and tried to retain the full width for the cmd
window.
To solve this problem, I propose we introduce the idea of a layout
"fingerprint". The fingerprint tries to capture, in an abstract way,
where the cmd window lives within the layout.
Only when two layouts have the same fingerprint will we attempt to
retain the cmd window size.
The fingerprint for a layout is represented as a string, the string is
a series of 'V' or 'H' characters, ending with a single 'C'
character. The series of 'V' and 'H' characters represent the
vertical or horizontal layouts that must be passed through to find the
cmd window.
Here are a few examples:
# This layout is equivalent to the builtin 'src' layout.
# Fingerprint: VC
tui new-layout example1 src 2 status 0 cmd 1
# This layout is equivalent to the builtin 'split' layout.
# Fingerprint: VC
tui new-layout example2 src 1 asm 1 status 0 cmd 1
# This is the same layout that was given at the top.
# Fingerprint: VHC
tui new-layout hsrc { -horizontal src 1 cmd 1 } 1 status 1
And so, when switching between example1 and example2, gdb knows that
the cmd window is, basically, in the same sort of position within the
layout, and will retain the cmd window size.
In contrast, when switching to the hsrc layout, gdb understands that
the position of the cmd window is different, and does not try to
retain the cmd window size.
Andrew Burgess [Tue, 1 Feb 2022 12:29:57 +0000 (12:29 +0000)]
gdb/tui: allow cmd window to change size in tui_layout_split::apply
When we switch layouts we call the tui_layout_split::apply member
function to reapply the layout, and recalculate all the window sizes.
One special case is the cmd window, which we try to keep at its
existing size.
However, in some cases it is not appropriate to keep the cmd window at
its existing size. I will describe two such cases here, in one, we
want the cmd window to reduce in size, and in the other, we want the
cmd window to grow in size.
Try these steps in a 80 columns, by 24 lines terminal:
(gdb) tui enable
(gdb) layout src
(gdb) winheight cmd 20
(gdb) layout split
You should see that the status window is missing from the new layout,
and that the cmd window has been placed over the border of the asm
window. The 'info win' output is:
(gdb) info win
Name Lines Columns Focus
src 3 80 (has focus)
asm 3 80
status 1 80
cmd 20 80
Notice that gdb has assigned 27 lines of screen space, even with the
border overlap between the src and asm windows, this is still 2 lines
too many.
The problem here is that after switching layouts, gdb has forced the
cmd window to retain its 20 line height. Really, we want the cmd
window to reduce in height so that the src and asm windows can occupy
their minimum required space.
This commit allows this (details on how are below). After this
commit, in the above situation, we now see the status window displayed
correctly, and the 'info win' output is:
(gdb) info win
Name Lines Columns Focus
src 3 80 (has focus)
asm 3 80
status 1 80
cmd 18 80
The cmd window has been reduced in size by 2 lines so that everything
can fit on the screen.
The second example is one which was discussed in a recent commit,
consider this case (still in the 80 column, 24 line terminal):
(gdb) tui enable
(gdb) tui new-layout conly cmd 1
(gdb) layout conly
(gdb) info win
Name Lines Columns Focus
cmd 8 80 (has focus)
(gdb)
This layout only contains a cmd window, which we would expect to
occupy the entire terminal. But instead, the cmd window only occupies
the first 8 lines, and the rest of the terminal is unused!
The reason is, again, that the cmd window is keeping its previous
size (8 lines).
After this commit things are slightly different, the 'info win' output
is now:
(gdb) info win
Name Lines Columns Focus
cmd 20 80 (has focus)
Which is a little better, but why only 20 lines? Turns out there's
yet another bug hitting this case. That bug will be addressed in a
later commit, so, for now, we're accepting the 20 lines.
What this commit does is modify the phase of tui_layout_split::apply
that handles any left over space. Usually, in "Step 2", each
sub-layout has a size calculated. As the size is an integer, then,
when all sizes are calculated we may have some space left over.
This extra space is then distributed between all the windows fairly
until all the space is used up.
When we consider windows minimum size, or fixed size windows, then it
is possible that we might try to use more space than is available,
this was our first example above. The same code that added extra
space to the windows, can also be used to reclaim space (in the over
allocation case) to allow all windows to fit.
The problem then is the cmd window, which we often force to a fixed
size. Inside the loop that handles the allocation of excess space, if
we find that we have tried every window, and still have space either
left to give, or we need to claim back more space, then, if the cmd
window was changed to a fixed size, we can change the cmd window back
to a non-fixed-size window, and proceed to either give, or take space
from the cmd window as needed.
Andrew Burgess [Tue, 1 Feb 2022 10:28:18 +0000 (10:28 +0000)]
gdb/tui: fairer distribution of excess space during apply
When applying layouts gdb computes the size of each window (or rather,
each sub-layout within a layout) using integer arithmetic. As this
rounds down the results, then, when all sub-layouts are sized, there
is the possibility that we have some space left over.
Currently, this space is just assigned to an arbitrary sub-layout.
This can result in some unbalanced results. Consider this set of
steps with current master:
(gdb) tui enable
(gdb) layout regs
(gdb) info win
Name Lines Columns Focus
regs 7 80
src 9 80 (has focus)
status 1 80
cmd 8 80
Notice the weird split between the src and regs windows, the original
layout specification has these windows given equal weight. The
problem is that, with rounding, both the regs and src windows are
initially sized to 7, the extra 2 lines are then arbitrarily added to
the src window.
In this commit, rather than add all the extra space to one single
window, I instead hand out the extra space 1 line at a time, looping
over all the sub-layouts. We take care to respect the min/max sizes,
and so, we now get this result:
(gdb) tui enable
(gdb) layout regs
(gdb) info win
Name Lines Columns Focus
regs 8 80
src 8 80 (has focus)
status 1 80
cmd 8 80
This looks more natural to me.
This is obviously a change in behaviour, and so, lots of the existing
tests need to be updated to take this into account. None of the
changes are huge, it's just a line or two (or column for width) moved
between windows.
Andrew Burgess [Tue, 1 Feb 2022 16:53:56 +0000 (16:53 +0000)]
gdb/tui: avoid fp exception when applying layouts
Consider:
(gdb) tui enable
(gdb) layout src
(gdb) tui new-layout conly cmd 1
(gdb) layout conly
After this, with current master, gdb crashes with a floating-point
exception.
The problem is that in tui_layout_split::apply, when we switch from
'src' to 'conly', we will try to retain the cmd window height. As
such, the cmd window will become a fixed size window, which decreases
the available_size, but doesn't count towards the total_weight.
As the cmd window is the only window, the total_weight stays at zero,
and, when we move into step 2, where we attempt to size the windows,
we perform a divide by zero, and crash.
After this commit we avoid the divide by zero, and just directly set
the window size based on the fixed size.
There is still a problem after this commit, when the conly layout is
selected the cmd window retains its original height, which will only
be part of the terminal. The rest of the terminal is left unused.
This issue will be addressed in a later commit, this commit is just
about the floating-point exception.
Andrew Burgess [Tue, 1 Feb 2022 13:36:58 +0000 (13:36 +0000)]
gdb/tui/testsuite: refactor new-layout.exp test
This commit changes the gdb.tui/new-layout.exp test to make use of a
list of test descriptions, and a loop to check each description in
turn. There's no change to what is actually tested after this commit.
In future commits I plan to add additional tests to this file, and
this will be easier now that all I have to do is add a new test
description to the list.
Andrew Burgess [Mon, 31 Jan 2022 12:13:38 +0000 (12:13 +0000)]
gdb/tui: add left_boxed_p and right_boxed_p member functions
When I initially saw this code in tui_layout_split::apply, I assumed
that this must be a bug:
/* Two adjacent boxed windows will share a border, making a bit
more size available. */
if (i > 0
&& m_splits[i - 1].layout->bottom_boxed_p ()
&& m_splits[i].layout->top_boxed_p ())
...
After all, the apply might be laying out a horizontal layout, right?
So checking bottom_boxed_p and top_boxed_p is clearly wrong.
Well, it turns on, that due to the implementations of these things,
bottom_boxed_p is equivalent to an imagined right_boxed_p, and
top_boxed_p is equivalent to an imagined left_boxed_p.
In this commit I've renamed both top_boxed_p and bottom_boxed_p to
first_edge_has_border_p and last_edge_has_border_p respectively, and
extended the comments in tui_layout_base to mention that these methods
handle both horizontal and vertical layouts.
Now, hopefully, the code shouldn't look like it only applies for
vertical layouts.
There should be no user visible changes after this commit.
Andrew Burgess [Wed, 26 Jan 2022 18:52:56 +0000 (18:52 +0000)]
gdb/tui: add a tui debugging flag
This commit adds 'set debug tui on|off' and 'show debug tui'. This
commit adds the control variable, and the printing macros in
tui/tui.h. I've then added some uses of these in tui.c and
tui-layout.c.
To help produce more useful debug output in tui-layout.c, I've added
some helper member functions in the class tui_layout_split, and also
moved the size_info struct out of tui_layout_split::apply into the
tui_layout_split class.
If tui debug is not turned on, then there should be no user visible
changes after this commit.
One thing to note is that, due to the way that the tui terminal is
often cleared, the only way I've found this useful is when I do:
(gdb) tui enable
(gdb) set logging file /path/to/file
(gdb) set logging debugredirect on
(gdb) set logging enable on
Additionally, gdb has some quirks when it comes to setting up logging
redirect and switching interpreters. Thus, the above only really
works if the logging is enabled after the tui is enabled, and disabled
again before the tui is disabled.
Enabling logging and switching interpreters can cause undefined
results, including crashes. This is an existing bug in gdb[1], and
has nothing directly to do with tui debug, but it is worth mentioning
here I think.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28948
Andrew Burgess [Mon, 24 Jan 2022 22:02:59 +0000 (22:02 +0000)]
gdb/tui: add new 'tui window width' command and 'winwidth' alias
This commit adds a new command 'tui window width', and an alias
'winwidth'. This command is equivalent to the old 'winheight'
command (which was recently renamed 'tui window height').
Even though I recently moved the old tui commands under the tui
namespace, and I would strongly encourage all new tui commands to be
added as 'tui ....' only (users can create their own top-level aliases
if they want), I'm breaking that suggestion here, and adding a
'winwidth' alias.
Given that we already have 'winheight' and have done for years, it
just didn't seem right to no have the matching 'winwidth'.
You might notice in the test that the window resizing doesn't quite
work right. I setup a horizontal layout, then grow and shrink the
windows. At the end of the test the windows should be back to their
original size...
... they are not. This isn't my fault, honest! GDB's window resizing
is a little ... temperamental, and is prone to getting things slightly
wrong during resizes, off by 1 type things. This is true for height
resizing, as well as the new width resizing.
Later patches in this series will rework the resizing algorithm, which
should improve things in this area. For now, I'm happy that the width
resizing is as good as the height resizing, given the existing quirks.
For the docs side I include a paragraph that explains how multiple
windows are required before the width can be adjusted. For
completeness, I've added the same paragraph to the winheight
description. With the predefined layouts this extra paragraph is not
really needed for winheight, as there are always multiple windows on
the screen. However, with custom layouts, this might not be true, so
adding the paragraph seems like a good idea.
As for the changes in gdb itself, I've mostly just taken the existing
height adjustment code, changed the name to make it generic 'size'
adjustment, and added a boolean flag to indicate if we are adjusting
the width or the height.
Andrew Burgess [Fri, 28 Jan 2022 12:00:31 +0000 (12:00 +0000)]
gdb/tui: rename tui_layout_split:set_weights_from_heights
In a following commit I'm going to add the ability to change the width
of a tui window (when in a horizontal layout). As a result, some of
the places where we currently hard-code references to height need to
be changed to handle either height, or width, based on whether we are
in a vertical, or horizontal layout.
This commit renames set_weights_from_heights to
set_weights_from_sizes, and makes the function use either the height,
or width as appropriate.
Currently, the only place that we call this function is from the
tui_layout_split::set_height function, in a part of the code we will
only reach for vertical layouts, so the new code is not actually being
used, but, this small change will help make later patches smaller, so
I'm proposing this as a stand alone change.
There should be no user visible changes after this commit.
Andrew Burgess [Mon, 24 Jan 2022 17:49:12 +0000 (17:49 +0000)]
gdb/tui: rename tui_layout_base::adjust_size to ::set_height
Rename tui_layout_base::adjust_size to tui_layout_base::set_height,
the new name more accurately reflects what this member function does,
and makes it easier for a later commit to add a new
tui_layout_base::set_width member function.
There should be no user visible changes after this commit.
Andrew Burgess [Mon, 24 Jan 2022 17:23:20 +0000 (17:23 +0000)]
gdb: move some commands into the tui namespace
There are a lot of tui related commands that live in the top-level
command name space, e.g. layout, focus, refresh, winheight.
Having them at the top level means less typing for the user, which is
good, but, I think, makes command discovery harder.
In this commit, I propose moving all of the above mentioned commands
into the tui namespace, so 'layout' becomes 'tui layout', etc. But I
will then add aliases so that the old commands will still work,
e.g. I'll make 'layout' an alias for 'tui layout'.
The benefit I see in this work is that tui related commands can be
more easily discovered by typing 'tui ' and then tab-completing. Also
the "official" command is now a tui-sub-command, this is visible in,
for example, the help output, e.g.:
(gdb) help layout
tui layout, layout
Change the layout of windows.
Usage: tui layout prev | next | LAYOUT-NAME
List of tui layout subcommands:
tui layout asm -- Apply the "asm" layout.
tui layout next -- Apply the next TUI layout.
tui layout prev -- Apply the previous TUI layout.
tui layout regs -- Apply the TUI register layout.
tui layout split -- Apply the "split" layout.
tui layout src -- Apply the "src" layout.
Which I think is a good thing, it makes it clearer that this is a tui
command.
I've added a NEWS entry and updated the docs to mention the new and
old command names, with the new name being mentioned first.
Simon Marchi [Sun, 3 Apr 2022 13:54:41 +0000 (09:54 -0400)]
gdb: fix gdb_print -> gdb_printf typo
This caused a build failure with !CXX_STD_THREAD.
Change-Id: I30f0c89c43a76f85c0db34809192644fa64a9d18
Alan Modra [Sun, 3 Apr 2022 12:04:53 +0000 (21:34 +0930)]
Move microblaze relax info to target specific data
Target specific data shouldn't be put in struct bfd_section.
* section.c (struct bfd_section): Delete relax and relax_count.
(BFD_FAKE_SECTION): Adjust to suit.
(struct relax_table): Move to..
* elf32-microblaze.c (struct relax_table): ..here.
(struct _microblaze_elf_section_data): New.
(microblaze_elf_section_data): Define.
(microblaze_elf_new_section_hook): New function.
(bfd_elf32_new_section_hook): Define.
(calc_fixup): Return a size_t. Adjust to suit new location of
relax and relax_count.
(microblaze_elf_relax_section): Adjust to suit new location of
relax and relax_count. Make some variables size_t.
* bfd-in2.h: Regenerate.
Alan Modra [Thu, 24 Mar 2022 05:12:52 +0000 (15:42 +1030)]
Revert commit
240d6706c6a2
PR 28592
PR 15994
PR 15935
* dwarf2.c (lookup_address_in_line_info_table): Return bool rather
than a range.
(comp_unit_find_nearest_line): Likewise. Return true if function
info found without line info.
(_bfd_dwarf2_find_nearest_line): Revert range handling code.
Alan Modra [Sun, 3 Apr 2022 11:23:44 +0000 (20:53 +0930)]
Regen bfd po/SRC-POTFILES.in
GDB Administrator [Sun, 3 Apr 2022 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
Tiezhu Yang [Mon, 21 Mar 2022 06:43:41 +0000 (14:43 +0800)]
gdb: rename floatformats_ia64_quad to floatformats_ieee_quad
It is better to rename floatformats_ia64_quad to floatformats_ieee_quad
to reflect the reality, and then we can clean up the related code.
As Tom Tromey said [1]:
These files are maintained in gcc and then imported into the
binutils-gdb repository, so any changes to them will have to
be proposed there first.
the related changes have been merged into gcc master now [2], it is time
to do it for gdb.
[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=
b2dff6b2d9d6
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
GDB Administrator [Sat, 2 Apr 2022 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in
John Baldwin [Fri, 1 Apr 2022 22:21:09 +0000 (15:21 -0700)]
Remove unused variable.
Aaron Merey [Fri, 1 Apr 2022 20:39:18 +0000 (16:39 -0400)]
gdb/debuginfod-support.c: Always display debuginfod errors
Errors encountered when downloading files from debuginfod servers
are not displayed if debuginfod verbosity is set to 0 (via
'set debuginfod verbose 0').
Tom recommended that these errors always be displayed, regardless
of the verbosity setting [1]. Fix this.
[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186350.html
John Baldwin [Fri, 1 Apr 2022 20:16:46 +0000 (13:16 -0700)]
Use I386_GSBASE_REGNUM in i386fbsd_get_thread_local_address.
32-bit x86 arches always the I386_*BASE_REGNUM values. Only code that
needs to support both 64-bit and 32-bit arches needs to use
tdep->fsbase_regnum to compute a segment base register number.
John Baldwin [Fri, 1 Apr 2022 20:16:46 +0000 (13:16 -0700)]
FreeBSD/x86: Read segment base registers from NT_X86_SEGBASES.
FreeBSD kernels recently grew a new register core dump note containing
the base addresses of the %fs and %gs segments (corresponding to the
%fsbase and %gsbase registers). Parse this note to permit inspecting
TLS variables in core dumps. Native processes already supported TLS
via older ptrace() operations.
John Baldwin [Fri, 1 Apr 2022 20:16:46 +0000 (13:16 -0700)]
Use pseudosections for NT_FREEBSD_X86_SEGBASES core dump notes.
This includes adding pseudosections when reading a core dump as well
as support for writing out a core dump note from a pseudosection.
bfd/ChangeLog:
* elf-bfd.h (elfcore_write_x86_segbases): New.
* elf.c (elfcore_grok_freebsd_note): Add pseudosections for
NT_FREEBSD_X86_SEGBASES register notes.
(elfcore_write_x86_segbases): New.
(elfcore_write_register_note): Write NT_FREEBSD_X86_SEGBASES
register notes.
John Baldwin [Fri, 1 Apr 2022 20:16:46 +0000 (13:16 -0700)]
Recognize FreeBSD core dump note for x86 segment base registers.
This core dump note contains the value of the base address of the %fs
and %gs segments for both i386 and amd64 core dumps. It is primarily
useful in resolving the address of TLS variables in core dumps.
binutils/ChangeLog:
* readelf.c (get_freebsd_elfcore_note_type): Handle
NT_FREEBSD_X86_SEGBASES.
include/ChangeLog:
* elf/common.h (NT_FREEBSD_X86_SEGBASES): Define.
John Baldwin [Fri, 1 Apr 2022 20:16:46 +0000 (13:16 -0700)]
elfcore_grok_freebsd_note: Remove checks of note->namesz.
This function is only called if the note name is "FreeBSD", so
checking the name size is unnecessary.
bfd/ChangeLog:
* elf.c (elfcore_grok_freebsd_note): Remove checks for namesz.
Andrew Burgess [Wed, 26 Jan 2022 18:41:59 +0000 (18:41 +0000)]
gdb/testing/tui: add new _csi_{L,S,T}
This patch was original part of this series:
https://sourceware.org/pipermail/gdb-patches/2022-March/186429.html
https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
I've pulled this out as it might be useful ahead of the bigger series
being merged.
This commit adds:
_csi_L - insert line
_csi_S - pan down
_csi_T - pan up
H.J. Lu [Thu, 24 Mar 2022 19:06:04 +0000 (12:06 -0700)]
x86: Remove bfd_arch_l1om and bfd_arch_k1om
Remove bfd_arch_l1om and bfd_arch_k1om since L1OM/K1OM support has been
removed from gas, ld and opcodes.
bfd/
* Makefile.am (ALL_MACHINES): Remove cpu-l1om.lo and cpu-k1om.lo.
(ALL_MACHINES_CFILES): Remove cpu-l1om.c and cpu-k1om.c.
* archures.c (bfd_mach_l1om): Removed.
(bfd_mach_l1om_intel_syntax): Likewise.
(bfd_mach_k1om): Likewise.
(bfd_mach_k1om_intel_syntax): Likewise.
(bfd_k1om_arch): Likewise.
(bfd_l1om_arch): Likewise.
(bfd_archures_list): Remove bfd_k1om_arch and bfd_l1om_arch
references.
* config.bfd (targ_selvecs): Remove l1om_elf64_vec.
l1om_elf64_fbsd_vec, k1om_elf64_vec and k1om_elf64_fbsd_vec.
(targ_archs): Remove bfd_l1om_arch and bfd_k1om_arch.
* configure.ac (k1om_elf64_vec): Removed.
(k1om_elf64_fbsd_vec): Likewise.
(l1om_elf64_vec): Likewise.
(l1om_elf64_fbsd_vec): Likewise.
* cpu-k1om.c: Removed.
* cpu-l1om.c: Likewise.
* elf64-x86-64.c (elf64_l1om_elf_object_p): Removed.
(elf64_k1om_elf_object_p): Likewise.
(l1om_elf64_vec): Removed.
(l1om_elf64_fbsd_vec): Likewise.
(k1om_elf64_vec): Likewise.
(k1om_elf64_fbsd_vec): Likewise.
(ELF_TARGET_OS): Undefine.
* targets.c (_bfd_target_vector): Remove k1om_elf64_vec,
k1om_elf64_fbsd_vec, l1om_elf64_vec and l1om_elf64_fbsd_vec.
* Makefile.in: Regenerate.
* bfd-in2.h: Likewise.
* configure: Likewise.
opcodes/
* configure.ac: Remove bfd_arch_l1om/bfd_arch_k1om references.
* disassemble.c (disassembler): Likewise.
* configure: Regenerate.
Simon Marchi [Thu, 31 Mar 2022 21:20:19 +0000 (17:20 -0400)]
gdb/ctf: pass partial symtab's filename to buildsym_compunit
I noticed that the CTF symbol reader passes the objfile's name to all
buildsym_compunit instances it creates. The result is that all
compunit_symtabs created have the same name, that of the objfile:
{ objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
{ ((struct compunit_symtab *) 0x621000286760)
debugformat ctf
producer (null)
name libbabeltrace2.so.0.0.0
dirname (null)
blockvector ((struct blockvector *) 0x6210003911d0)
user ((struct compunit_symtab *) (null))
{ symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003911f0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
{ ((struct compunit_symtab *) 0x621000275c10)
debugformat ctf
producer (null)
name libbabeltrace2.so.0.0.0
dirname (null)
blockvector ((struct blockvector *) 0x621000286710)
user ((struct compunit_symtab *) (null))
{ symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x621000286730)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
Notice the two "name libbabeltrace2.so.0.0.0".
Change it to pass the partial_symtab's filename instead. The output
becomes:
{ objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
{ ((struct compunit_symtab *) 0x621000295610)
debugformat ctf
producer (null)
name libbabeltrace2.so.0.0.0
dirname (null)
blockvector ((struct blockvector *) 0x6210003a15d0)
user ((struct compunit_symtab *) (null))
{ symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003a15f0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
{ ((struct compunit_symtab *) 0x621000288700)
debugformat ctf
producer (null)
name current-thread.c
dirname (null)
blockvector ((struct blockvector *) 0x6210002955c0)
user ((struct compunit_symtab *) (null))
{ symtab /home/simark/src/babeltrace/src/lib/current-thread.c ((struct symtab *) 0x6210002955e0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
Note that the first compunit_symtab still has libbabeltrace2.so.0.0.0 as
its name. This is because the CTF symbol reader really creates a
partial symtab named like this. It appears to be because the debug info
contains information that has been factored out of all CUs and is at the
"top-level" of the objfile, outside any real CU. So it creates a
partial symtab and an artificial CU that's named after the objfile.
Change-Id: I576316bab2a3668adf87b4e6cebda900a8159b1b
Simon Marchi [Thu, 31 Mar 2022 21:20:18 +0000 (17:20 -0400)]
gdb: print compunit_symtab name in "maint info symtabs"
I think it would make sense to print a compunit_symtab's name in "maint
info symtabs". If you are looking for a given CU in the list, that's
probably the field you will be looking at. As the doc of
compunit_symtab::name says, it is not meant to be a reliable file name,
it is for debugging purposes (and "maint info symtabs" exists for
debugging purposes).
Sample output with the new field:
(gdb) maintenance info symtabs
{ objfile /home/simark/build/binutils-gdb-one-target/gdb/a.out ((struct objfile *) 0x613000005d00)
{ ((struct compunit_symtab *) 0x621000131630)
debugformat DWARF 5
producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
name test.c
dirname /home/simark/build/binutils-gdb-one-target/gdb
blockvector ((struct blockvector *) 0x621000131d10)
user ((struct compunit_symtab *) (null))
{ symtab test.c ((struct symtab *) 0x6210001316b0)
fullname (null)
linetable ((struct linetable *) 0x621000131d40)
}
{ symtab /home/simark/build/binutils-gdb-one-target/gdb/test.h ((struct symtab *) 0x6210001316e0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
{ symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000131710)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
{ ((struct compunit_symtab *) 0x6210001170a0)
debugformat DWARF 5
producer GNU C17 11.2.0 -mtune=generic -march=x86-64 -g3 -O0
name foo.c
dirname /home/simark/build/binutils-gdb-one-target/gdb
blockvector ((struct blockvector *) 0x621000131580)
user ((struct compunit_symtab *) (null))
{ symtab foo.c ((struct symtab *) 0x621000117120)
fullname (null)
linetable ((struct linetable *) 0x6210001315b0)
}
{ symtab /usr/include/stdc-predef.h ((struct symtab *) 0x621000117150)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
}
Change-Id: I17b87adfac2f6551cb5bda30d59f6c6882789211
Simon Marchi [Thu, 31 Mar 2022 21:20:17 +0000 (17:20 -0400)]
gdb/ctf: don't create a buildsym_compunit when building partial symbols
I am trying to do some changes to buildsym_compunit, so I am auditing
the current uses. Something seems odd with this use of
buildsym_compunit (that this patch removes).
A buildsym_compunit is normally used when building a compunit_symtab.
That is, when expanding a partial symtab into a full compunit symtab.
In ctfread.c, a buildsym_compunit is created in ctf_start_archive, which
is only used when creating partial symtabs. At this moment, I don't
see how that's useful. ctf_start_archive creates a new
buildsym_compunit and starts a subfile. But that buildsym_compunit is
never used again. It's just overriden in ctf_start_symtab, which means
we leak the old buildsym_compunit, I suppose.
Remove ctf_start_archive completely. Add an assert in
ctf_start_symtab to verify that we are not overwriting an existing
buildsym_compunit (meaning we'd leak the existing one). This assert
triggers without the other part of the fix. When doing:
$ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
...
(gdb) maintenance expand-symtabs
/home/simark/src/binutils-gdb/gdb/ctfread.c:1255: internal-error: ctf_start_symtab: Assertion `!ccp->builder' failed.
Change-Id: I666d146454a019f08e7305f3a1c4a974d27b4592
Tom Tromey [Thu, 10 Mar 2022 00:26:37 +0000 (17:26 -0700)]
Style URLs in GDB output
I noticed that GDB will display URLs in a few spots. This changes
them to be styled. Originally I thought I'd introduce a new "url"
style, but there aren't many places to use this, so I just reused
filename styling instead. This patch also changes the debuginfod URL
list to be printed one URL per line. I think this is probably a bit
easier to read.
GDB Administrator [Fri, 1 Apr 2022 00:00:12 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Thu, 31 Mar 2022 18:20:02 +0000 (14:20 -0400)]
gdb: initialize ctf_context::builder in create_partial_symtab
I built a random project with -gctf, in order to test the CTF support in
GDB. With my ASan/UBSan/etc-enabled build of GDB, I get:
$ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
...
Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0...
/home/simark/src/binutils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebebe for type 'struct buildsym_compunit', which requires 8 byte alignment
0xbebebebebebebebe: note: pointer points here
The 0xbebebebebebebebe value is a sign that the ctf_context::builder
field is uninitialized. The problem probably goes under the radar if
the field happens to be zero-initialized, because ctf_start_archive
contains this code:
if (ccx->builder == nullptr)
{
ccx->builder = new buildsym_compunit (of,
of->original_name, nullptr, language_c, 0);
If the field was zero-initialized (by chance), this will create a new
buildsym_compunit. But if the field was purposely filled with random
bytes by one of the sanitizers, we won't create a buildsym_compunit here
and we'll continue with ccx->builder equal to 0xbebebebebebebebe.
Fix this the easy way by initializing ccx->builder where the other
ctf_context fields are initialized (yeah, this code could be made nicer
C++, but I am going for the obvious fix here).
With this patch, this passes cleanly on my system:
$ make check TESTS="gdb.ctf/*.exp" RUNTESTFLAGS="CC_FOR_TARGET=/opt/gcc/git/bin/gcc"
# of expected passes 40
... where /opt/gcc/git/bin/gcc is a gcc with CTF support, given my
system gcc does not have it.
Change-Id: Idea1b0cf3e3708b72ecb16b1b60222439160f9b9
Tom Tromey [Fri, 4 Mar 2022 18:29:27 +0000 (11:29 -0700)]
Remove dbx mode
This patch removes gdb's dbx mode. Regression tested on x86-64 Fedora
34.
H.J. Lu [Thu, 24 Feb 2022 15:34:01 +0000 (07:34 -0800)]
gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xml
1. Since 32bit-pkeys.xml and 64bit-pkeys.xml are identical, consolidate
them into a single keys.xml.
2. Enable PKU for x32 to fix:
$ gdbserver :123456 x32-program
...
.../gdbserver/regcache.cc:255: A problem internal to GDBserver has been detected
.
Unknown register pkru requested
on Tiger Lake.
Simon Marchi [Mon, 17 Jan 2022 16:27:36 +0000 (11:27 -0500)]
gdb/linux-nat: remove check based on current_inferior in linux_handle_extended_wait
The check removed by this patch, using current_inferior, looks wrong.
When debugging multiple inferiors with the Linux native target and
linux_handle_extended_wait is called, there's no guarantee about which
is the current inferior. The vfork-done event we receive could be for
any inferior. If the vfork-done event is for a non-current inferior, we
end up wrongfully ignoring it. As a result, the core never processes a
TARGET_WAITKIND_VFORK_DONE event, program_space::breakpoints_not_allowed
is never cleared, and breakpoints are never reinserted. However,
because the Linux native target decided to ignore the event, it resumed
the thread - while breakpoints out. And that's bad.
The proposed fix is to remove this check. Always report vfork-done
events and let infrun's logic decide if it should be ignored. We don't
save much cycles by filtering the event here.
Add a test that replicates the situation described above. See comments
in the test for more details.
Change-Id: Ibe33c1716c3602e847be6c2093120696f2286fbf
Simon Marchi [Tue, 18 Jan 2022 19:33:57 +0000 (14:33 -0500)]
gdbserver/linux: set lwp !stopped when failing to resume
I see some failures, at least in gdb.multi/multi-re-run.exp and
gdb.threads/interrupted-hand-call.exp. Running `stress -C $(nproc)` at
the same time as the test makes those tests relatively frequent.
Let's take gdb.multi/multi-re-run.exp as an example. The failure looks
like this, an unexpected "no resumed":
continue
Continuing.
No unwaited-for children left.
(gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=2: iter=1: continue until exit
The situation is:
- Inferior 1 is stopped somewhere, it won't really play a role here.
- Inferior 2 has 2 threads, both stopped.
- We resume inferior 2, the leader thread is expected to exit, making
the process exit.
From GDB's perspective, a failing run looks like this:
[infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] do_target_wait: Found 2 inferiors, starting at #1
[infrun] random_pending_event_thread: None found.
[remote] wait: enter
[remote] Packet received: T0506:
20dcffffff7f0000;07:
20dcffffff7f0000;10:
9551555555550000;thread:pae4cd.ae4cd;core:e;
[remote] wait: exit
[infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
[infrun] print_target_wait_results: 713933.713933.0 [Thread 713933.713933],
[infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
[infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_TRAP
[infrun] clear_step_over_info: clearing step over info
[infrun] context_switch: Switching context from 0.0.0 to 713933.713933.0
[infrun] handle_signal_stop: stop_pc=0x555555555195
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 0
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] process_event_stop_test: no stepping, continue
[remote] Sending packet: $Z0,
555555555194,1#8e
[remote] Packet received: OK
[infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [713933.713933.0] at 0x555555555195
[remote] Sending packet: $QPassSignals:e;10;14;17;1a;1b;1c;21;24;25;2c;4c;97;#0a
[remote] Packet received: OK
[remote] Sending packet: $vCont;c:pae4cd.-1#9f
[infrun] prepare_to_wait: prepare_to_wait
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
[infrun] fetch_inferior_event: exit
[infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] do_target_wait: Found 2 inferiors, starting at #0
[infrun] random_pending_event_thread: None found.
[remote] wait: enter
[remote] Packet received: N
[remote] wait: exit
[infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
[infrun] print_target_wait_results: -1.0.0 [process -1],
[infrun] print_target_wait_results: status->kind = NO_RESUMED
[infrun] handle_inferior_event: status->kind = NO_RESUMED
[remote] Sending packet: $Hgp0.0#ad
[remote] Packet received: OK
[remote] Sending packet: $qXfer:threads:read::0,1000#92
[remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="
40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="
40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="
40b6c6f7ff7f0000"/>\n</threads>\n
[infrun] stop_waiting: stop_waiting
[remote] Sending packet: $qXfer:threads:read::0,1000#92
[remote] Packet received: l<threads>\n<thread id="pae4cb.ae4cb" core="3" name="multi-re-run-1" handle="
40c7c6f7ff7f0000"/>\n<thread id="pae4cb.ae4cc" core="2" name="multi-re-run-1" handle="
40b6c6f7ff7f0000"/>\n<thread id="pae4cd.ae4ce" core="1" name="multi-re-run-2" handle="
40b6c6f7ff7f0000"/>\n</threads>\n
[infrun] infrun_async: enable=0
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target extended-remote
[infrun] fetch_inferior_event: exit
We can see that we resume the inferior with vCont;c, but got NO_RESUMED.
When the test passes, we get an EXITED status to indicate the process
has exited.
From GDBserver's point of view, it looks like this. The logs contain
some logging I added and that are part of this patch.
[remote] getpkt: getpkt ("vCont;c:pae4cf.-1"); [no ack sent]
[threads] resume: enter
[threads] thread_needs_step_over: Need step over [LWP 713931]? Ignoring, should remain stopped
[threads] thread_needs_step_over: Need step over [LWP 713932]? Ignoring, should remain stopped
[threads] get_pc: pc is 0x555555555195
[threads] thread_needs_step_over: Need step over [LWP 713935]? No, no breakpoint found at 0x555555555195
[threads] get_pc: pc is 0x7ffff7d35a95
[threads] thread_needs_step_over: Need step over [LWP 713936]? No, no breakpoint found at 0x7ffff7d35a95
[threads] resume: Resuming, no pending status or step over needed
[threads] resume_one_thread: resuming LWP 713935
[threads] proceed_one_lwp: lwp 713935
[threads] resume_one_lwp_throw: continue from pc 0x555555555195
[threads] resume_one_lwp_throw: Resuming lwp 713935 (continue, signal 0, stop not expected)
[threads] resume_one_lwp_throw: NOW ptid=713935.713935.0 stopped=0 resumed=0
[threads] resume_one_thread: resuming LWP 713936
[threads] proceed_one_lwp: lwp 713936
[threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95
[threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
[threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
[threads] resume: exit
[threads] wait_1: enter
[threads] wait_1: [<all threads>]
[threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
[threads] resume_stopped_resumed_lwps: resuming stopped-resumed LWP LWP 713935.713936 at
7ffff7d35a95: step=0
[threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95
[threads] resume_one_lwp_throw: Resuming lwp 713936 (continue, signal 0, stop not expected)
[threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
[threads] operator(): check_zombie_leaders: leader_pid=713931, leader_lp!=NULL=1, num_lwps=2, zombie=0
[threads] operator(): check_zombie_leaders: leader_pid=713935, leader_lp!=NULL=1, num_lwps=2, zombie=1
[threads] operator(): Thread group leader 713935 zombie (it exited, or another thread execd).
[threads] delete_lwp: deleting 713935
[threads] wait_for_event_filtered: exit (no unwaited-for LWP)
sigchld_handler
[threads] wait_1: ret = null_ptid, TARGET_WAITKIND_NO_RESUMED
[threads] wait_1: exit
What happens is:
- We resume the leader (713935) successfully.
- The leader exits.
- We resume the secondary thread (713936), we get ESRCH. This is
expected this the leader has exited.
- resume_one_lwp_throw throws, it's caught by resume_one_lwp.
- resume_one_lwp checks with check_ptrace_stopped_lwp_gone that the
failure can be explained by the LWP becoming zombie, and swallows the
error.
- Note that this means that the secondary lwp still has stopped==1.
- wait_1 is called, probably because linux_process_target::resume marks
the async pipe at the end.
- The exit event isn't ready yet, probably because the machine is under
load, so waitpid returns nothing.
- check_zombie_leaders detects that the leader is zombie and deletes
- We try to find a resumed (non-stopped) LWP to get an event from,
there's none since the leader (that was resumed) is now deleted, and
the secondary thread is still marked stopped.
wait_for_event_filtered returns -1, causing wait_1 to return
NO_RESUMED.
What I notice here is that there is some kind of race between the
availability of the process' exit notification and the call to wait_1
that results from marking the async pipe at the end of resume.
I think what we want from this wait_1 invocation is to keep waiting, as
we will eventually get thread exit notifications for both of our
threads.
The fix I came up with is to mark the secondary thread as !stopped (or
resumed) when we fail to resume it. This makes wait_1 see that there is
at least one resume lwp, so it won't return NO_RESUMED. I think this
makes sense to consider it resumed, because we are going to receive an
exit event for it. Here's the GDBserver logs with the fix applied:
[threads] resume: enter
[threads] thread_needs_step_over: Need step over [LWP 724595]? Ignoring, should remain stopped
[threads] thread_needs_step_over: Need step over [LWP 724596]? Ignoring, should remain stopped
[threads] get_pc: pc is 0x555555555195
[threads] thread_needs_step_over: Need step over [LWP 724597]? No, no breakpoint found at 0x555555555195
[threads] get_pc: pc is 0x7ffff7d35a95
[threads] thread_needs_step_over: Need step over [LWP 724598]? No, no breakpoint found at 0x7ffff7d35a95
[threads] resume: Resuming, no pending status or step over needed
[threads] resume_one_thread: resuming LWP 724597
[threads] proceed_one_lwp: lwp 724597
[threads] resume_one_lwp_throw: continue from pc 0x555555555195
[threads] resume_one_lwp_throw: Resuming lwp 724597 (continue, signal 0, stop not expected)
[threads] resume_one_lwp_throw: NOW ptid=724597.724597.0 stopped=0 resumed=0
[threads] resume_one_thread: resuming LWP 724598
[threads] proceed_one_lwp: lwp 724598
[threads] resume_one_lwp_throw: continue from pc 0x7ffff7d35a95
[threads] resume_one_lwp_throw: Resuming lwp 724598 (continue, signal 0, stop not expected)
[threads] resume_one_lwp_throw: ptrace errno = 3 (No such process)
[threads] resume: exit
[threads] wait_1: enter
[threads] wait_1: [<all threads>]
sigchld_handler
[threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
[threads] operator(): check_zombie_leaders: leader_pid=724595, leader_lp!=NULL=1, num_lwps=2, zombie=0
[threads] operator(): check_zombie_leaders: leader_pid=724597, leader_lp!=NULL=1, num_lwps=2, zombie=1
[threads] operator(): Thread group leader 724597 zombie (it exited, or another thread execd).
[threads] delete_lwp: deleting 724597
[threads] wait_for_event_filtered: sigsuspend'ing
sigchld_handler
[threads] wait_for_event_filtered: waitpid(-1, ...) returned 724598, ERRNO-OK
[threads] wait_for_event_filtered: waitpid 724598 received 0 (exited)
[threads] filter_event: 724598 exited
[threads] wait_for_event_filtered: waitpid(-1, ...) returned 724597, ERRNO-OK
[threads] wait_for_event_filtered: waitpid 724597 received 0 (exited)
[threads] wait_for_event_filtered: waitpid(-1, ...) returned 0, ERRNO-OK
sigchld_handler
[threads] wait_1: ret = LWP 724597.724598, exited with retcode 0
[threads] wait_1: exit
Change-Id: Idf0bdb4cb0313f1b49e4864071650cc83fb3c100
Simon Marchi [Wed, 30 Mar 2022 00:58:58 +0000 (20:58 -0400)]
gdb/testsuite/tui: implement _csi_P proc
Since commit
3cd522938792 ("Change the pager to a ui_file"), I see these
errors when running gdb.tui/scroll.exp:
ERROR: invalid command name "_csi_P"
while executing
"::gdb_tcl_unknown _csi_P 2"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::gdb_tcl_unknown $args"
(procedure "::unknown" line 5)
invoked from within
"_csi_P 2"
("eval" body line 1)
invoked from within
"eval _csi_$cmd $params"
It looks like GDB is emitting a CSI that it did not emit before, the
"Delete character" one:
https://vt100.net/docs/vt510-rm/DCH.html
Implement it.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I5bf86b6104d51b0623a26a69df83d1ca9a4851b7
Simon Marchi [Thu, 31 Mar 2022 16:50:41 +0000 (12:50 -0400)]
gdb: fix use of fprintf_filtered in top.c
A race condition in how patches were pushed causes this build failure:
CXX top.o
/home/simark/src/binutils-gdb/gdb/top.c: In function ‘void print_gdb_configuration(ui_file*)’:
/home/simark/src/binutils-gdb/gdb/top.c:1622:3: error: ‘fprintf_filtered’ was not declared in this scope; did you mean ‘printf_unfiltered’?
1622 | fprintf_filtered (stream, _("\
| ^~~~~~~~~~~~~~~~
fprintf_filtered has been removed, gdb_printf must be used now. Fix
this.
Change-Id: I6a172ba0d53dab2e7cc43ed0ed2696c82925245b
Richard Sandiford [Thu, 31 Mar 2022 16:51:16 +0000 (17:51 +0100)]
aarch64: Relax check for RNG system registers
FEAT_RNG is an optional Armv8.5-A extension, but it can be backported
to earlier architectures as well. GAS previously made the RNG registers
conditional on having both armv8.5-a and +rng, but only +rng should be
required.
This seems to be the only feature that was handled like this.
opcodes/
* aarch64-opc.c (SR_RNG): Don't require V8_5.
gas/
* testsuite/gas/aarch64/rng-1.s, testsuite/gas/aarch64/rng-1.d: New
test.
Eli Zaretskii [Thu, 31 Mar 2022 16:22:18 +0000 (19:22 +0300)]
* gdb/top.c (print_gdb_configuration): Announce --enable-threading.
This includes the reporting of --enable/disable-threading as part of
the GDB configuration description.
Simon Marchi [Mon, 17 Jan 2022 16:27:35 +0000 (11:27 -0500)]
gdb/infrun: add reason parameter to stop_all_threads
Add a "reason" parameter, only used to show in debug messages what is
the reason for stopping all threads. This helped me understand the
debug logs while adding some new uses of stop_all_threads, so I am
proposing to merge it.
Change-Id: I66c8c335ebf41836a7bc3d5fe1db92c195f65e55
Simon Marchi [Mon, 10 Jan 2022 17:50:17 +0000 (12:50 -0500)]
gdb/testsuite: update copyright years in gdb.base/vfork-follow-parent.*
I forgot to do this before pushing the previous commit.
Change-Id: Ia343f702e8357d0fd109e9ddd778973e91862805
Simon Marchi [Mon, 10 Jan 2022 17:50:17 +0000 (12:50 -0500)]
gdb: test vfork + follow-fork-mode=parent + detach-on-fork=off
The particular behavior we have when using that combination of settings
doesn't seem tested at all (at least, I don't find it if I grep for "Can
not resume the parent process"). Add a simple test for that.
Change-Id: Ib9454a615abba661b42f1b15056df73ed1bcd4c5
Nick Clifton [Thu, 31 Mar 2022 14:43:42 +0000 (15:43 +0100)]
Accept the + character as part of filenames for MRI scripts.
Rainer Orth [Thu, 31 Mar 2022 08:34:52 +0000 (10:34 +0200)]
Fix procfs.c compilation
procfs.c doesn't compile on Solaris:
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c: In member function ‘virtual bool procfs_target::info_proc(const char*, info_proc_what)’:
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3302:3: error: ‘gdb_argv’ was not declared in this scope
3302 | gdb_argv built_argv (args);
| ^~~~~~~~
/vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3303:20: error: ‘built_argv’ was not declared in this scope; did you mean ‘buildargv’?
3303 | for (char *arg : built_argv)
| ^~~~~~~~~~
| buildargv
Fixed by including "gdbsupport/buildargv.h".
Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11.
GDB Administrator [Thu, 31 Mar 2022 00:00:06 +0000 (00:00 +0000)]
Automatic date update in version.in
Simon Marchi [Wed, 30 Mar 2022 17:08:55 +0000 (13:08 -0400)]
gdb/testsuite: add tests for Term
While trying to review Andrew's patch here [1], I thought I spotted a
bug in the handling of a CSI, but I had no way to know for sure. So I
thought it would be useful to have unit tests for the handling of
control characters and control sequences of our toy terminal
implementation. It might help avoid chasing bugs in the GDB TUI when in
reality it's a problem with the testsuite's terminal implementation.
Add the gdb.tui/tuiterm.exp file to do that. All currently supported
control sequences and characters are tested, except _csi_m (the one that
handles colors and stuff). _csi_m should probably be tested too, but it
will require more work.
Fix a few issues that the tests spotted:
- backspace: according to [3] (table 4-1), a backspace when the cursor
is at the beginning of a line should have no effect. Our
implementation did wrap to the end of the previous line. Change our
implementation to match the doc (and the test).
- insert character: this control sequence is supposed to insert blank
characters, shifting all the rest of the line right. The current
implementation moves N characters right, but it overwrites the
characters on the right instead of shifting them. It also doesn't
insert blank characters at the cursor.
- Cursor down, forward, next line: off-by-one error when reaching the
end of the display.
- erase in display, line: off-by-one errors.
- vertical line position absolute: allowed setting the cursor outside
the display, when it should clamp it to the display size.
I found that this web page [2] gave some good clues on the expected
behavior of some control characters or sequences that some other pages
didn't.
[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186433.html
[2] https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences
[3] https://vt100.net/docs/vt510-rm/chapter4.html#S4.3.3
Change-Id: Iab4141fdcfb7459d1b7c45cc63bd1fcb50a78d5d
Tom Tromey [Tue, 29 Mar 2022 20:36:10 +0000 (14:36 -0600)]
Only allow QUIT on the main thread
Pedro pointed out that gdb worker threads should not react to quits.
While I don't think that the new DWARF reader can call QUIT from a
worker thread (and I don't think the existing minsym threading code
can either), it seems safest to address this before checking in the
new code. This patch arranges for the QUIT macro to only work on the
main thread.
Tom Tromey [Wed, 30 Mar 2022 15:32:18 +0000 (09:32 -0600)]
Use gdb_printf and gdb_vprintf in more places
Luis pointed out that I missed a spot in the gdb_printf conversion --
namely aarch64-nat.c. While looking at this, I found another spot in
darwin-nat.c that I also missed. I can't build either of these, but I
think this patch should fix the problems.
Tom Tromey [Mon, 28 Mar 2022 15:46:55 +0000 (09:46 -0600)]
Consolidate definition of current_directory
I noticed that both gdbserver and gdb define current_directory.
However, as it is referenced by gdbsupport, it seemed better to define
it there as well. This patch also moves the declaration to
pathstuff.h. Tested by rebuilding.
Tom Tromey [Thu, 17 Mar 2022 13:59:43 +0000 (07:59 -0600)]
Decode "dynamic" interface types in Ada
In Ada, if a class implements an interface and has a dynamic
superclass, then the "offset to top" -- the offset that says how to
turn a pointer to the interface into a pointer to the whole object --
is stored in the object itself. This patch changes GDB to understand
this.
Because this only touches Ada code, and because Joel already reviewed
it internally, I am checking it in.
Jeff Law [Wed, 30 Mar 2022 00:05:51 +0000 (20:05 -0400)]
Fix for MUL instruction on the v850
* sim/v850/simops.c (Multiply64): Properly test if we need to
negate either of the operands.
* sim/testsuite/v850/mul.cgs: New test.
GDB Administrator [Wed, 30 Mar 2022 00:00:07 +0000 (00:00 +0000)]
Automatic date update in version.in
Tom Tromey [Mon, 14 Mar 2022 23:00:37 +0000 (17:00 -0600)]
Remove two unused hooks
I noticed that a couple of deprecated hooks aren't ever called, so
they can't really be used by Insight. This patch removes them
entirely. I checked the Insight sources, and these aren't mentioned
there, either.
Tom Tromey [Tue, 4 Jan 2022 00:12:22 +0000 (17:12 -0700)]
Remove unnecessary calls to wrap_here and gdb_flush
Various spots in gdb currently know about the wrap buffer, and so are
careful to call wrap_here to be certain that all output has been
flushed.
Now that the pager is just an ordinary stream, this isn't needed, and
a simple call to gdb_flush is enough.
Similarly, there are places where gdb prints to gdb_stderr, but first
flushes gdb_stdout. stderr_file already flushes gdb_stdout, so these
aren't needed.
Tom Tromey [Sun, 2 Jan 2022 20:59:56 +0000 (13:59 -0700)]
Minor comment updates in utils.h
This patch updates some comments in utils.h to more closely reflect
the new reality.
Tom Tromey [Sun, 2 Jan 2022 20:56:42 +0000 (13:56 -0700)]
Remove vfprintf_styled
Nothing calls vfprintf_styled any more, so remove it.
Tom Tromey [Sun, 2 Jan 2022 20:08:45 +0000 (13:08 -0700)]
Remove ui_out_flag::unfiltered_output
There is no longer any need for ui_out_flag::unfiltered_output --
nothing ever sets this flag. This used to be needed to make the
_unfiltered output work, but now only printf_unfiltered can be used,
and it uses the puts_unfiltered method. This patch removes the flag
and the dead code.
Tom Tromey [Sun, 2 Jan 2022 18:55:39 +0000 (11:55 -0700)]
Rename fprintf_symbol_filtered
fprintf_symbol_filtered is misnamed, because whether filtering happens
is now up to the stream. This renames it to fprintf_symbol, which
isn't a great name (the first "f" doesn't mean much and the second one
is truly meaningless here), but "print_symbol" was already taken.
Tom Tromey [Sun, 2 Jan 2022 18:54:06 +0000 (11:54 -0700)]
Rename puts_filtered_tabular
puts_filtered_tabular is now misnamed, because whether filtering
happens is now up to the stream. So, rename it. (This function is
pretty weird, and should probably be rewritten to avoid using the
chars_printed global, and moved into objc-lang.c. However, I haven't
done so.)
Tom Tromey [Sun, 2 Jan 2022 18:53:15 +0000 (11:53 -0700)]
Rename print_spaces_filtered
print_spaces_filtered is now misnamed, because whether filtering
happens is up to the stream. So, rename it.
Tom Tromey [Sun, 2 Jan 2022 18:46:15 +0000 (11:46 -0700)]
Unify gdb printf functions
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
Tom Tromey [Sun, 2 Jan 2022 18:42:07 +0000 (11:42 -0700)]
Unify gdb putc functions
Now that filtered and unfiltered output can be treated identically, we
can unify the putc family of functions. This is done under the name
"gdb_putc". Most of this patch was written by script.
Tom Tromey [Sun, 2 Jan 2022 18:36:44 +0000 (11:36 -0700)]
Unify gdb puts functions
Now that filtered and unfiltered output can be treated identically, we
can unify the puts family of functions. This is done under the name
"gdb_puts". Most of this patch was written by script.
Tom Tromey [Sun, 2 Jan 2022 18:13:35 +0000 (11:13 -0700)]
Unify vprintf functions
Now that filtered and unfiltered output can be treated identically, we
can unify the vprintf family of functions: vprintf_filtered,
vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered. (For
the gdb_stdout variants, recall that only printf_unfiltered gets truly
unfiltered output at this point.) This removes one such function and
renames the remaining two to "gdb_vprintf". All callers are updated.
Much of this patch was written by script.
Tom Tromey [Sat, 1 Jan 2022 22:25:53 +0000 (15:25 -0700)]
Remove fputs_styled_unfiltered
fputs_styled_unfiltered is only called from cli_ui_out, so remove it.
This area will be further simplified in future patches.
Tom Tromey [Sat, 1 Jan 2022 20:18:17 +0000 (13:18 -0700)]
Change the pager to a ui_file
This rewrites the output pager as a ui_file implementation.
A new header is introduced to declare the pager class. The
implementation remains in utils.c for the time being, because there
are some static globals there that must be used by this code. (This
could be cleaned up at some future date.)
I went through all the text output in gdb to ensure that this change
should be ok. There are a few cases:
* Any existing call to printf_unfiltered is required to be avoid the
pager. This is ensured directly in the implementation.
* All remaining calls to the f*_unfiltered functions -- the ones that
take an explicit ui_file -- either send to an unfiltered stream
(e.g., gdb_stderr), which is obviously ok; or conditionally send to
gdb_stdout
I investigated all such calls by searching for:
grep -e '\bf[a-z0-9_]*_unfiltered' *.[chyl] */*.[ch] | grep -v gdb_stdlog | grep -v gdb_stderr
This yields a number of candidates to check.
* The breakpoint _print_recreate family, and
save_trace_state_variables. These are used for "save" commands
and so are fine.
* Things printing to a temporary stream. Obviously ok.
* Disassembly selftests.
* print_gdb_help - this is non-obvious, but ok because paging isn't
yet enabled at this point during startup.
* serial.c - doens't use gdb_stdout
* The code in compile/. This is all printing to a file.
* DWARF DIE dumping - doesn't reference gdb_stdout.
* Calls to the _filtered form -- these are all clearly ok, because if
they are using gdb_stdout, then filtering will still apply; and if
not, then filtering never applied and still will not.
Therefore, at this point, there is no longer any distinction between
all the other _filtered and _unfiltered calls, and they can be
unified.
In this patch, take special note of the vfprintf_maybe_filtered and
ui_file::vprintf change. This is one instance of the above idea,
erasing the distinction between filtered and unfiltered -- in this
part of the change, the "unfiltered_output" flag is never passe to
cli_ui_out. Subsequent patches will go much further in this
direction.
Also note the can_emit_style_escape changes in ui-file.c. Checking
against gdb_stdout or gdb_stderr was always a bit of a hack; and now
it is no longer needed, because this is decision can be more fully
delegated to the particular ui_file implementation.
ui_file::can_page is removed, because this patch removed the only call
to it.
I think this is the main part of fixing PR cli/7234.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7234
Tom Tromey [Sat, 1 Jan 2022 20:35:13 +0000 (13:35 -0700)]
Remove vfprintf_styled_no_gdbfmt
This removes vfprintf_styled_no_gdbfmt, inlining it at the sole point
of call.
Tom Tromey [Sat, 1 Jan 2022 08:34:48 +0000 (01:34 -0700)]
Add style-escape methods to ui_file
This adds emit_style_escape and reset_style methods to ui_file. These
aren't used yet, but they will be once the pager is converted to be a
ui_file subclass.
Tom Tromey [Fri, 31 Dec 2021 21:34:07 +0000 (14:34 -0700)]
Add puts_unfiltered method to ui_file
When the pager is rewritten as a ui_file, gdb will still need a way to
bypass the filtering. After examining a few approaches, I chose this
patch, which adds a puts_unfiltered method to ui_file. For most
implementations of ui_file, this will just delegate to puts. This
patch also switches printf_unfiltered to use the new method.
Tom Tromey [Sat, 1 Jan 2022 19:18:47 +0000 (12:18 -0700)]
Only have one API for unfiltered output
At the end of this series, the use of unfiltered output will be very
restricted -- only places that definitely need it will use it. To
this end, I thought it would be good to reduce the number of
_unfiltered APIs that are exposed. This patch changes gdb so that
only printf_unfiltered exists. (After this patch, the f* variants
still exist as well, but those will be removed later.)
Tom Tromey [Sat, 8 Jan 2022 23:31:44 +0000 (16:31 -0700)]
Remove some uses of printf_unfiltered
A number of spots call printf_unfiltered only because they are in code
that should not be interrupted by the pager. However, I believe these
cases are all handled by infrun's blanket ban on paging, and so can be
converted to the default (_filtered) API.
After this patch, I think all the remaining _unfiltered calls are ones
that really ought to be. A few -- namely in complete_command -- could
be replaced by a scoped assignment to pagination_enabled, but for the
remainder, the code seems simple enough like this.
Tom Tromey [Sat, 8 Jan 2022 23:23:18 +0000 (16:23 -0700)]
Use unfiltered output in annotate.c
It seems to me that annotations should not be filtered. While it
might be weird for an annotation-based UI to use the pager, it's not,
I think, out of the question. This patch makes this change.
Tankut Baris Aktemur [Tue, 29 Mar 2022 14:19:10 +0000 (16:19 +0200)]
gdb/remote: use current_inferior in read_ptid if multi-process not supported
When parsing the ptid out of a reply package, if the multi-process
extensions are not supported, use current_inferior's pid as the pid of
the reported thread, instead of inferior_ptid. This is needed because
the inferior_ptid may be null_ptid although a legit context exists,
due to a prior context switch via switch_to_inferior_no_thread.
Below is a scenario that illustrates what could go wrong. First,
setup a multi-target scenario. This is needed, because in a
multi-target setting, the inferior_ptid is cleared out before waiting
on targets. The second inferior below sits on top of a remote target.
Multi-process packets are disabled.
$ # First, spawn a process with PID 26253 to attach to later.
$ gdb-up a.out
Reading symbols from a.out...
(gdb) maint set target-non-stop on
(gdb) set remote multiprocess-feature-packet off
(gdb) start
...
(gdb) add-inferior -no-connection
[New inferior 2]
Added inferior 2
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) target extended-remote | gdbserver --multi -
Remote debugging using | gdbserver --multi -
Remote debugging using stdio
(gdb) attach 26253
Attaching to Remote target
Attached; pid = 26253
[New Thread 26253]
[New inferior 3]
Reading /tmp/a.out from remote target...
...
[New Thread 26253]
...
Reading /usr/local/lib/debug/....debug from remote target...
>>> GDB seems to hang here.
After attaching to a process and reading some library files, GDB
seems to hang. One interesting thing to note is that
[New Thread 26253]
appears twice. We also see
[New inferior 3]
Running the same scenario with "debug infrun on" reveals more details.
...
(gdb) attach 26253
[infrun] scoped_disable_commit_resumed: reason=attaching
Attaching to Remote target
Attached; pid = 26253
[New Thread 26253]
[infrun] infrun_async: enable=1
[infrun] attach_command: immediately after attach:
[infrun] attach_command: thread 26253.26253.0, executing = 1, resumed = 0, state = RUNNING
[infrun] clear_proceed_status_thread: 26253.26253.0
[infrun] reset: reason=attaching
[infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
[infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] do_target_wait: Found 2 inferiors, starting at #1
[infrun] random_pending_event_thread: None found.
[infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
[infrun] print_target_wait_results: 26253.26253.0 [Thread 26253],
[infrun] print_target_wait_results: status->kind = STOPPED, sig = GDB_SIGNAL_0
[infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_0
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 0
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] context_switch: Switching context from 0.0.0 to 26253.26253.0
[infrun] handle_signal_stop: stop_pc=0x7f849d8cf151
[infrun] stop_waiting: stop_waiting
[infrun] stop_all_threads: starting
[infrun] stop_all_threads: pass=0, iterations=0
[New inferior 3]
Reading /tmp/a.out from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /tmp/a.out from remote target...
Reading symbols from target:/tmp/a.out...
[New Thread 26253]
[infrun] stop_all_threads: 4723.4723.0 not executing
[infrun] stop_all_threads: 26253.26253.0 not executing
[infrun] stop_all_threads: 42000.26253.0 executing, need stop
[infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
[infrun] print_target_wait_results: -1.0.0 [Thread 0],
[infrun] print_target_wait_results: status->kind = IGNORE
[infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
[infrun] print_target_wait_results: -1.0.0 [Thread 0],
[infrun] print_target_wait_results: status->kind = IGNORE
GDB tried to stop Thread 42000.26253.0, which does not exist, and we
are waiting for a stop event that will never happen. The PID in
'42000.26253.0', namely 42000, is the PID of magic_null_ptid.
It comes from gdb/remote.c:read_ptid:
/* Since the stub is not sending a process id, then default to
what's in inferior_ptid, unless it's null at this point. If so,
then since there's no way to know the pid of the reported
threads, use the magic number. */
if (inferior_ptid == null_ptid)
pid = magic_null_ptid.pid ();
else
pid = inferior_ptid.pid ();
if (obuf)
*obuf = pp;
return ptid_t (pid, tid);
Because multi-process was turned off, GDB did not parse an explicitly
specified PID. Furthermore, inferior_ptid == null_ptid, and
eventually GDB picked the PID from magic_null_ptid.
If target-non-stop is not turned on at the beginning, the same bug
reveals itself as a duplicated thread as shown below.
# Same setup as above, without 'maint set target-non-stop on'.
...
(gdb) attach 26253
Attaching to Remote target
Attached; pid = 26253
[New inferior 3]
...
[New Thread 26253]
...
(gdb) info threads
Id Target Id Frame
1.1 process 13517 "a.out" main () at test.c:3
* 2.1 Thread 26253 "a.out" 0x00007f12750c5151 in read () from target:/lib/x86_64-linux-gnu/libc.so.6
3.1 Thread 26253 "a.out" Remote 'g' packet reply is too long (expected 560 bytes, got 2496 bytes): 00feffffffffffff000a3a75127f000051510c75127f0000000400000000000060d24ef6af5500000000000000000000680d000000000000b85b31e3fc7f0000c0283a75127f000000e55b75127f000010d04ef6af550000460200000000000060c73975127f0000a0d23975127f0000000a3a75127f0000000000000000000051510c75127f000046020000330000002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff0000000000000000000000000000000000000000000080143a75127f000080143a75127f000040143a75127f000040143a75127f00007d0000007e0000007f00000080000000300c3a75127f0000300c3a75127f00000e000000000000000e0000000000000000000000000000000000000000000000ffffffffffffffffffffffffffffffff0400000004000000040000000400000020143a75127f000020143a75127f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000000000000000000000e55b75127f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb)
Fix the problem by preferring current_inferior()'s pid instead of
magic_null_ptid.
Regression-tested on X86-64 Linux.
Co-authored-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Andrew Burgess [Sat, 26 Mar 2022 13:41:33 +0000 (13:41 +0000)]
gdb/testsuite: fix test failure when building against readline v7
The test added in the commit:
commit
a6b413d24ccc5d76179bab866834e11fd6fec294
Date: Fri Mar 11 14:44:03 2022 +0000
gdb: work around prompt corruption caused by bracketed-paste-mode
Was not written with readline 7 in mind, only readline 8+. Between
readline 7 and 8 the escape sequence used to disable bracketed paste
mode changed, an additional '\r' character was added to the end. In
fact, it was the addition of this '\r' character that triggered the
issue for which the above commit is part of the solution.
Anyway, the test tries to spot the case where the output from GDB is
not perfect, but does have the above work around applied. However,
the pattern in the test assumes that the problematic '\r' will be
present, and this is only true for readline 8+. With readline 7 the
test was failing.
In this commit I generalise the pattern a little so that the test will
still KFAIL with readline 7.
It's a little unfortunate that the test is KFAILing with readline 7,
as without the problematic '\r' there's actually no reason that GDB
couldn't "do the right thing" in this case, in which case, the test
would PASS, but that would require changes within GDB itself.
My preference then is that initially we patch the test to get it
KFAILing, then in a separate commit I can modify GDB so that it can
PASS with readline 7.