| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This commit changes the format of 'disassemble /r' to match GNU
objdump. Specifically, GDB will now display the instruction bytes in
as 'objdump --wide --disassemble' does.
Here is an example for RISC-V before this patch:
(gdb) disassemble /r 0x0001018e,0x0001019e
Dump of assembler code from 0x1018e to 0x1019e:
0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0)
0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0)
0x00010196 <call_me+74>: 61 65 lui a0,0x18
0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704
0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf>
End of assembler dump.
And here's an example after this patch:
(gdb) disassemble /r 0x0001018e,0x0001019e
Dump of assembler code from 0x1018e to 0x1019e:
0x0001018e <call_me+66>: fe842603 lw a2,-24(s0)
0x00010192 <call_me+70>: fec42583 lw a1,-20(s0)
0x00010196 <call_me+74>: 6561 lui a0,0x18
0x00010198 <call_me+76>: 6a850513 addi a0,a0,1704
0x0001019c <call_me+80>: 22f1 jal 0x10368 <printf>
End of assembler dump.
There are two differences here. First, the instruction bytes after
the patch are grouped based on the size of the instruction, and are
byte-swapped to little-endian order.
Second, after the patch, GDB now uses the bytes-per-line hint from
libopcodes to add whitespace padding after the opcode bytes, this
means that in most cases the instructions are nicely aligned.
It is still possible for a very long instruction to intrude into the
disassembled text space. The next example is x86-64, before the
patch:
(gdb) disassemble /r main
Dump of assembler code for function main:
0x0000000000401106 <+0>: 55 push %rbp
0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp
0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi)
0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax
0x0000000000401119 <+19>: 5d pop %rbp
0x000000000040111a <+20>: c3 ret
End of assembler dump.
And after the patch:
(gdb) disassemble /r main
Dump of assembler code for function main:
0x0000000000401106 <+0>: 55 push %rbp
0x0000000000401107 <+1>: 48 89 e5 mov %rsp,%rbp
0x000000000040110a <+4>: c7 87 d8 00 00 00 01 00 00 00 movl $0x1,0xd8(%rdi)
0x0000000000401114 <+14>: b8 00 00 00 00 mov $0x0,%eax
0x0000000000401119 <+19>: 5d pop %rbp
0x000000000040111a <+20>: c3 ret
End of assembler dump.
Most instructions are aligned, except for the very long instruction.
Notice too that for x86-64 libopcodes doesn't request that GDB group
the instruction bytes. This matches the behaviour of objdump.
In case the user really wants the old behaviour, I have added a new
modifier 'disassemble /b', this displays the instruction byte at a
time. For x86-64, which never groups instruction bytes, /b and /r are
equivalent, but for RISC-V, using /b gets the old layout back (except
that the whitespace for alignment is still present). Consider our
original RISC-V example, this time using /b:
(gdb) disassemble /b 0x0001018e,0x0001019e
Dump of assembler code from 0x1018e to 0x1019e:
0x0001018e <call_me+66>: 03 26 84 fe lw a2,-24(s0)
0x00010192 <call_me+70>: 83 25 c4 fe lw a1,-20(s0)
0x00010196 <call_me+74>: 61 65 lui a0,0x18
0x00010198 <call_me+76>: 13 05 85 6a addi a0,a0,1704
0x0001019c <call_me+80>: f1 22 jal 0x10368 <printf>
End of assembler dump.
Obviously, this patch is a potentially significant change to the
behaviour or /r. I could have added /b with the new behaviour and
left /r alone. However, personally, I feel the new behaviour is
significantly better than the old, hence, I made /r be what I consider
the "better" behaviour.
The reason I prefer the new behaviour is that, when I use /r, I almost
always want to manually decode the instruction for some reason, and
having the bytes displayed in "instruction order" rather than memory
order, just makes this easier.
The 'record instruction-history' command also takes a /r modifier, and
has been modified in the same way as disassemble; /r gets the new
behaviour, and /b has been added to retain the old behaviour.
Finally, the MI command -data-disassemble, is unchanged in behaviour,
this command now requests the raw bytes of the instruction, which is
equivalent to the /b modifier. This means that the MI output will
remain backward compatible.
|
|
Add another test for the output of MI command -data-disassemble. The
new check validates the format of the 'opcodes' field, specifically,
this test checks that the field contains a series of bytes, separated
by a single space.
We also check that the bytes are in the correct order, that is, the
first byte is from the lowest address, and subsequent bytes are from
increasing addresses.
The motivation for this test (besides more tests being generally good)
is that I plan to make changes to how opcode bytes are displayed in
the disassembler output, and I want to ensure that I don't break any
existing MI behaviour.
There should be no user visible changes to GDB after this commit.
|
|
On openSUSE Tumbleweed, I run into:
...
FAIL: gdb.mi/mi-sym-info.exp: List all functions from debug information only
...
The problem is in matching this string:
...
{name="_start",type="void (void)",description="void _start(void);"}
...
using regexp fun_re, which requires a line field:
...
set fun_re \
"\{line=\"$decimal\",name=${qstr},type=${qstr},description=${qstr}\}"
...
Fix this by making the line field optional in fun_re.
Tested on x86_64-linux.
|
|
Since commit 52b920c5d20 ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
for ppc64le"), the test-case fails with target board cc-with-debug-names, due
to missing .debug_aranges info.
Add the missing .debug_aranges info.
Also add a file_id option to Dwarf::assemble, to make it possible to contribute
to an already open file.
Tested on x86_64-linux.
|
|
Consider the test-case contained in this patch.
With g++ (7.5.0) we have for "ptype A":
...
type = class A {
public:
int a;
A(void);
~A();
}
...
and with clang++ (13.0.1):
...
type = class A {
public:
int a;
A(void);
~A(void);
}
...
and we observe that the destructor is printed differently.
There's a difference in debug info between the two cases: in the clang case,
there's one artificial parameter, but in the g++ case, there are two, and
these similar cases are handled differently in cp_type_print_method_args.
This is due to this slightly convoluted bit of code:
...
i = staticp ? 0 : 1;
if (nargs > i)
{
while (i < nargs)
...
}
else if (varargs)
gdb_printf (stream, "...");
else if (language == language_cplus)
gdb_printf (stream, "void");
...
The purpose of "i = staticp ? 0 : 1" is to skip the printing of the implicit
this parameter.
In commit 5f4d1085085 ("c++/8218: Destructors w/arguments"), skipping of other
artificial parameters was added, but using a different method: rather than
adjusting the potential loop start, it skips the parameter in the loop.
The observed difference in printing is explained by whether we enter the loop:
- in the clang case, the loop is not entered and we print "void".
- in the gcc case, the loop is entered, and nothing is printed.
Fix this by rewriting the code to:
- always enter the loop
- handle whether arguments need printing in the loop
- keep track of how many arguments are printed, and
use that after the loop to print void etc.
such that we have the same for both gcc and clang:
...
A(void);
~A(void);
...
Note that I consider the discussion of whether we want to print:
- A(void) / ~A(void), or
- A() / ~A()
out-of-scope for this patch.
Tested on x86_64-linux.
|
|
A user noticed that gdb would assert when printing a certain array
with array-indexes enabled. This turned out to be caused by the array
having an index type of Character, which is completely valid in Ada.
This patch changes the Ada support to recognize Character as a
discrete type, and adds some tests.
Because this is Ada-specific and was also reviewed internally, I am
checking it in.
|
|
If some command in there gives the wrong answer, we currently have to
wait for a timeout for the test to continue. For instance, I currently
see:
print *val->type
$1 = Python Exception <class 'gdb.error'>: Cannot take address of method length.
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: pretty print type (timeout)
We can avoid this and modernize the test at the same time by using the
-prompt option of gdb_test.
gdb_test_no_output currently accepts a -prompt_re option (the variable
name passed to parse_args defines the option name), but I think
it's a typo. It's supposed to be -prompt, like gdb_test. I can't find
anything using -prompt_re using grep. Change it to just "prompt".
Change-Id: Icc0a9a0ef482e62460c708bccdd544c11d711eca
|
|
When running gdb.gdb/python-helper.exp, I get some timeouts:
continue
Continuing.
print 1
FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb (timeout)
At this time, GDB is actually processing the stop and reading in some
CUs. selftest_setup does bump the timeout, but it's not for the whole
test.
Since debugging GDB with GDB is (unfortunately) a bit slow, bump the
timeout for the whole duration of the setup and body. On my optimized
build, the command takes just a bit more than the current timeout of 10
seconds. But it's much slower if running the test on an unoptimized
build, so I think it's necessary to bump the timeout for that in any
case.
Change-Id: I4d38285870e76c94f9d0bfdb60648a2e7f2cfa5d
|
|
When running test-case gdb.dwarf2/dw2-unspecified-type-foo.c with target board
unix/-m32, I run into:
...
(gdb) PASS: gdb.dwarf2/dw2-unspecified-type.exp: ptype foo
p ((int (*) ()) foo) ()^M
$1 = -135698472^M
...
Add the missing "return 0" in foo, which fixes this.
Tested on x86_64-linux.
|
|
The test gdb.tui/tui-missing-src.exp fails on my CI machine, and I
concluded that it is caused by the long source directory name:
/home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb
The long name causes some particular redrawing that doesn't happen for
shorter directories, and causes a Term::command call to return too
early.
This can be reproduced by cloning the binutils-gdb repo in a directory
with a name similar to the one shown above.
$ pwd
/home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/build/gdb
$ make check-read1 TESTS="gdb.tui/tui-missing-src.exp"
FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
FAIL: gdb.tui/tui-missing-src.exp: f2.c must be displayed in source window
FAIL: gdb.tui/tui-missing-src.exp: check source box is empty after return
FAIL: gdb.tui/tui-missing-src.exp: Back in main
Note that using "make check" instead of "make check-read1" only shows
the last 2 failures for me.
When running gdb.tui/tui-missing-src.exp in a directory with a shorter
name, the terminal looks like this by the time the "checking if inside
f2" test runs:
Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 23):
0 +-...ld/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-missing-src/f2.c-+
1 | 1 |
2 | 2 int |
3 | 3 f2 (int x) |
4 | 4 { |
5 | > 5 x <<= 1; |
6 | 6 return x+5; |
7 | 7 } |
8 | 8 |
9 | 9 |
10 | 10 |
11 | 11 |
12 | 12 |
13 | 13 |
14 +------------------------------------------------------------------------------+
15 multi-thre Thread 0x7ffff7cc07 In: f2 L5 PC: 0x555555555143
16 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
17 missing-src/main.c:6
18 (gdb) next
19 (gdb) step
20 f2 (x=4)
21 at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
22 missing-src/f2.c:5
23 (gdb)
PASS: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
When running the `Term::command "step"` just before, GDB writes the
"step", which makes the `wait_for` proc go in the "looking for the
prompt" mode, to know when the command's execution is complete. As some
new output appears, lines that must disappear are deleted using the
"Delete Line" operation [1] and some new ones are drawn. The source
window gets redrawn with the contents of the f2.c file. Then, GDB
writes the prompt (at line 23 above), which satisfies `wait_for`, which
then returns. The state of the terminal is therefore correct for the
"check if inside f2" and "f2.c must be displayed in the source window"
tests.
In the non-working case, the terminal looks like this by the time the
"check if inside f2" test runs:
Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 17):
0 +------------------------------------------------------------------------------+
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | [ No Source Available ] |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 +------------------------------------------------------------------------------+
15 multi-thre Thread 0x7ffff7cc1b In: main L7 PC: 0x555555555128
16 sing-src/main.c:6
17 (gdb) ary breakpoint 1, main ()
18 at /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd6
19 4/target_board/unix/src/binutils-gdb/build/gdb/testsuite/outputs/gdb.tui/tui-mis
20 sing-src/main.c:6
21 (gdb) next
22 (gdb) step
23
FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
What happened is: GDB wrote the "step" command, which make the
`wait_for` proc go in its "looking for the prompt" mode. However,
curses decided to redraw whatever scrolled up to line 17 using some
standard character insertion operations:
+++ Cursor Down (1), cursor: (16, 0) -> (17, 0)
+++ Inserting string '('
+++ Inserted char '(', cursor: (17, 0) -> (17, 1)
+++ Inserted string '(', cursor: (17, 0) -> (17, 1)
+++ Inserting string 'g'
+++ Inserted char 'g', cursor: (17, 1) -> (17, 2)
+++ Inserted string 'g', cursor: (17, 1) -> (17, 2)
+++ Inserting string 'd'
+++ Inserted char 'd', cursor: (17, 2) -> (17, 3)
+++ Inserted string 'd', cursor: (17, 2) -> (17, 3)
+++ Inserting string 'b'
+++ Inserted char 'b', cursor: (17, 3) -> (17, 4)
+++ Inserted string 'b', cursor: (17, 3) -> (17, 4)
+++ Inserting string ')'
+++ Inserted char ')', cursor: (17, 4) -> (17, 5)
+++ Inserted string ')', cursor: (17, 4) -> (17, 5)
+++ Inserting string ' '
+++ Inserted char ' ', cursor: (17, 5) -> (17, 6)
+++ Inserted string ' ', cursor: (17, 5) -> (17, 6)
And that causes `wait_for` to think the "step" command is complete.
This is wrong, as the prompt at line 17 isn't the prompt drawn after the
completion of the "step" command. The subsequent tests now run with a
partially updated screen (what is shown above) and obviously fail.
The ideal way to fix this would be for `wait_for` to be smarter, to
avoid it confusing the different prompts drawn.
However, I would also like to reduce the variations in TUI test results
due to the directories (source and build) in which tests are ran. TUI
tests are more prone to differences in test results due to variations in
directory names than other tests, as it makes curses take different
redrawing decisions. So in this patch, I propose to make TUI tests use
"set filename-display basename", which makes GDB omit directory names
when it prints file names. This way, regardless of where you run the
tests, you should get the same results (all other things being equal).
Doing this happens to fix my failures and makes my CI happy (which in
turns makes me happy). To be clear, I understand that this does not fix
the root issue of `proc wait_for` being confused. However, it makes TUI
test runs be more similar for everyone, such that there's less chance of
TUI tests randomly failing for somebody. If some other change triggers
the `wait_for` problem again in the future, hopefully everybody will see
the problem and we can work on getting it fixed more easily than if just
one unlucky person sees the problem.
Note that there are other reasons why TUI tests could vary, like
different curses library versions taking different re-drawing decisions.
However, I think my change is a good step towards more stable test
results.
[1] https://vt100.net/docs/vt510-rm/DL.html
Change-Id: Ib18da83317e7b78a46f77892af0d2e39bd261bf5
|
|
GDB's testsuite can override dejagnu's default_target_compile if the
system provided dejagnu installation does not provide support to compile
languages GDB needs.
Recent version of dejagnu (1.6.3, installed on RHEL-9) includes ba60272
"Establish a default C compiler by evaluating [find_gcc] if no other
compiler is given."[1]. This commit removed calls such as
`set_board_info compiler "[find_gcc]"` from the various baseboards
and has default_target_compile call `find_gcc` itself to find a compiler
if none was specified by the board description.
On systems with dejagnu-1.6.3, if GDB's overrides is needed to support
languages still unknown to dejagnu, we end up in the following
situation:
- The system board files do not set the C compiler anymore,
- GDB's replacement for default_target_compile assumes that the
compiler should have been set up by the board file.
In this situation, no one sets the C compiler for the board and as a
result many test are not compiled and not executed:
[...]
Running .../gdb/testsuite/gdb.base/bt-on-error-and-warning.exp ...
gdb compile failed, default_target_compile: No compiler to compile with
Running .../gdb/testsuite/gdb.base/dprintf-non-stop.exp ...
gdb compile failed, default_target_compile: No compiler to compile with
Running .../gdb/testsuite/gdb.base/structs3.exp ...
gdb compile failed, default_target_compile: No compiler to compile with
[...]
We are observing this error with ROCgdb[2], a downstream port of GDB
supporting AMD GPUs. This port needs to use GDB's override of
default_target_compile to compile HIP programs since dejagnu does not
provide support for this language yet.
This patch changes gdb_default_target_compile_1 in a similar way
default_target_compile has been updated so both implementations remain
compatible. Even if this is not strictly required by GDB just yet,
I believe keeping both implementations in sync desirable.
Using board files provided with dejagnu <=1.6.2 is still supported: if
the compiler is set by the board file, gdb_default_target_compile_1 uses
it and does not need `find_gcc`.
Patch tested on x86_64 RHEL-9 and ubuntu-20.04 on top of GDB and ROCgdb.
[1] http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=ba60272a5ac6f6a7012acca03f596a6ed003f044
[2] https://github.com/ROCm-Developer-Tools/ROCgdb
Change-Id: Ibff52684d9cab8243a7c6748ecbd29f50c37e669
|
|
I noticed that, from Python, I could register a new TUI window that
had whitespace in its name, like this:
gdb.register_window_type('my window', MyWindowType)
however, it is not possible to then use this window in a new TUI
layout, e.g.:
(gdb) tui new-layout foo my window 1 cmd 1
Unknown window "my"
(gdb) tui new-layout foo "my window" 1 cmd 1
Unknown window ""my"
(gdb) tui new-layout foo my\ window 1 cmd 1
Unknown window "my\"
GDB clearly uses the whitespace to split the incoming command line.
I could fix this by trying to add a mechanism by which we can use
whitespace within a window name, but it seems like an easier solution
if we just forbid whitespace within a window name. Not only is this
easier, but I think this is probably the better solution, identifier
names with spaces in would mean we'd need to audit all the places a
window name could be printed and ensure that the use of a space didn't
make the output ambiguous.
So, having decided to disallow whitespace, I then thought about other
special characters. We currently accept anything as a window name,
and I wondered if this was a good idea.
My concerns were about how special characters used in a window name
might cause confusion, for example, we allow '$' in window names,
which is maybe fine now, but what if one day we wanted to allow
variable expansion when creating new layouts? Or what about starting
a window name with '-'? We already support a '-horizontal' option,
what if we want to add more in the future? Or use of the special
character '{' which has special meaning within a new layout?
In the end I figured it might make sense to place some restrictive
rules in place, and then relax the rules later if/when users complain,
we can consider each relaxation as its requested.
So, I propose that window names should match this regular expression:
[a-zA-Z][-_.a-zA-Z0-9]*
There is a chance that there is user code in the wild which will break
with the addition of this change, but hopefully adapting to the new
restrictions shouldn't be too difficult.
|
|
The testsuite implicitly tests GDB's ability to step through epilogues
in multiple tests, without doing it explicitly anywhere. This is
unfortunate, as clang does not emit epilogue information, so using clang
on our testsuite makes many tests fail. This patch adds a central,
explicit test for walking through the epilogue so we can safely remove
this from other tests and have them working with clang.
The test created attempts to step through a simple epilogue, an
epilogue that ends on another epilogue, and epilogues leading to other
function calls.
|
|
gdb.base/skip.exp was making use of a fixed number of step commands to
exit some functions. This caused some problems when using clang to test
GDB, as GDB would need fewer steps to reach the desired spots. For
instance, when testing in the section "step after disabling 3", the log
looks like this:
Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
(gdb) step
bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
21 return 1;
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 1
step
foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
42 return 0;
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 2
step
main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:34
34 test_skip_file_and_function ();
(gdb) step
test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:59
59 test_skip ();
(gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 3
step
test_skip () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:48
48 }
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 4
step
test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:60
60 skip1_test_skip_file_and_function ();
(gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 5
This shows that the feature is working but because the inferior lands in
a different location, it registers as a failure. Seeing as along with
this difference, there are also some differences that depend on gcc
versions (where gdb might stop back at line 32 before entering foo), it
would not be easy to test for this behavior using steps and analzing
where the inferior stops at each point. On the other hand, using
gdb_step_until is not feasible because we'd possibly gloss over stepping
into baz and rendering the whole test useless. Instead, skip.exp now
uses finish to leave functions, synchronizing through compilers and
compiler versions. Some test names were also changed to be a bit more
descriptive. The new log looks like this, independently of compiler used:
Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
(gdb) step
bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
21 return 1;
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into bar
finish
Run till exit from #0 bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
Value returned is $2 = 1
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: return from bar
step
foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
42 return 0;
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into foo
finish
Run till exit from #0 foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
32 x = baz ((bar (), foo ()));
Value returned is $3 = 0
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: Return from foo
step
34 test_skip_file_and_function ();
(gdb) PASS: gdb.base/skip.exp: step after disabling 3: step and skip baz
|
|
When using clang as the compiler for the target, gdb.base/jit-elf.exp
was failing because the filename displayed when GDB attached to the
inferior was only showing up as with a relative path, like so:
(gdb) attach 3674146
Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146
Reading symbols from /lib64/libm.so.6...
Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
(No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */
(gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
While gcc's output is as follows:
(gdb) attach 3592961
Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961
Reading symbols from /lib64/libm.so.6...
Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
(No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */
(gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
This difference only happens when GDB's configure is ran using a
relative path, but seeing as testing the full path is not important for
this specific test, it feels worth fixing anyway. To fix the false
positive, the regexp for checking where gdb has stopped was relaxed a
little to allow the relative path.
|
|
When trying to test gdb.base/msym-bp-shl.exp using clang, it would have
many failures because one of the version of the foo function was being
optimized away. Adding __attribute__ ((used)) to it fixed this.
|
|
When testing gdb.base/skip-inline.exp using clang, we get failures
when trying to step out of functions, since clang requires one fewer
step when compared to gcc. The inferior gets increasingly out of sync
as the test continues because of this difference, which generates those
failures.
This commit fixes this by switching those hardcoded steps to
gdb_step_until, to guarantee that the inferior is always synced to what
the test expects. This approach does not work for the parts that use
step 2 or step 3, so when we identify that clang is being used, those
tests are skipped.
|
|
When running gdb.base/skip-solib.exp, the backtrace tests could fail with
compilers that associated epilogue instructions with the last statement
line of the function, instead of associating it with the closing brace,
despite the feature being fully functional. As an example, when testing
skipping the function square, the testsuite would show
Breakpoint 1, main () at (...)/binutils-gdb/gdb/testsuite/gdb.base/skip-solib-main.c:5
5 return square(0);
(gdb) step
0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
(gdb) PASS: gdb.base/skip-solib.exp: ignoring solib file: step
bt
#0 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
#1 0x00007ffff7cef60c in __libc_start_main_impl () from /lib64/libc.so.6
#2 0x0000000000401065 in _start ()
(gdb) FAIL: gdb.base/skip-solib.exp: ignoring solib file: bt
Which means that the feature is working, the testsuite is just
mis-identifying it. To avoid this problem, the skipped function calls
have been sent to a line before `return`, so epilogues won't factor in.
|
|
Different compilers link the epilogue of functions to different lines.
As an example, gcc links it to the closing brace of the function,
whereas clang links it to the last statement of the function. This
difference is important for the testsuite, since the where GDB will land
after a step can be wildly different. Where possible, this dependency
should be side-stepped in the testsuite, but it isn't always possible,
so this commit adds a gdb_caching_proc that is able to detect where the
epilogue is linked, so tests can react accordingly.
|
|
We currently have a single test for GDB's debuginfod support, this is
gdb.debuginfod/fetch_src_and_symbols.exp, this script does all the
setup, starts debuginfod, and then does the testing.
This commit tries to split the existing script in two, there is a new
library lib/debuginfod-support.exp, which contains a helper functions
related to running debuginfod tests. All the code in the new library
is basically copied from the existing test case (which is why I
retained the copyright date range on the new library), with some minor
adjustments to try and make the code a little more generic.
One change I made, for example, is the library offers functions to
shut down debuginfod, previously we just relied on expect shutting
down debuginfod when dejagnu completed.
The existing test script is updated to make use of the new library
code, and this test is still passing for me. The only change in the
test results is a single test where I changed the name to remove the
port number from the test name - the port number can change from run
to run, so could make it hard to compare test results.
I have also done a little light house keeping on the original test
script, updating and adding new comments, and making use of
proc_with_prefix in a couple of places.
|
|
With the test-case included in this commit, we run into this FAIL:
...
(gdb) p var^M
During symbol reading: file index out of range^M
$1 = 0^M
(gdb) FAIL: gdb.dwarf2/dw2-no-code-cu.exp: p var with no complaints
...
This is a regression since commit 6d263fe46e0 ("Avoid bad breakpoints with
--gc-sections"), which contains this change in read_file_scope:
...
- handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
+ if (lowpc != highpc)
+ handle_DW_AT_stmt_list (die, cu, fnd, lowpc);
...
The change intends to avoid a problem with a check in
lnp_state_machine::check_line_address, but also prevents the file and dir
tables from being read, which causes the complaint.
Fix the FAIL by reducing the scope of the "lowpc != highpc" condition to the
call to dwarf_decode_lines in handle_DW_AT_stmt_list.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29561
|
|
This commit adds a GDB test case which tests GDB's BFD error handler
hook for suppressing output of all but the first identical messages.
See the comment at the beginning of bfd-errors.exp for details about
this new test.
I've tested this test for both 32- and 64-bit ELF files and also
on both little endian and big endian machines. It also works for
both native and remote targets. The only major restriction is that
it only works for ELF targets.
|
|
With the test-case included in the patch, we run into:
...
(gdb) info types -q std::nullptr_t^M
During symbol reading: unsupported tag: 'DW_TAG_unspecified_type'^M
^M
File /usr/include/c++/7/x86_64-suse-linux/bits/c++config.h:^M
2198: typedef decltype(nullptr) std::nullptr_t;^M
(gdb) FAIL: gdb.dwarf2/nullptr_t.exp: info types -q std::nullptr_t \
without complaint
...
Fix the complaint by handling DW_TAG_unspecified_type in new_symbol, and verify
in the test-case using "maint print symbols" that the symbol exists.
Tested on x86_64-linux, with gcc 7.5.0 and clang 13.0.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17271
|
|
On a powerpc system with gcc 12 built to default to 128-bit IEEE long double,
I run into:
...
(gdb) print find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)^M
$8 = 0 + 0i^M
(gdb) FAIL: gdb.base/varargs.exp: print \
find_max_long_double_real(4, ldc1, ldc2, ldc3, ldc4)
...
This is due to incorrect handling of the argument in ppc64_sysv_abi_push_param.
Fix this and similar cases, and expand the test-case to test handling of
homogeneous aggregates.
Tested on ppc64le-linux, power 10.
Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com>
Tested-by: Carl Love <cel@us.ibm.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29543
|
|
[ Another attempt at fixing the problem described in commit cd919f5533c
("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp"). ]
When running the test-case gdb.dwarf2/dw2-dir-file-name.exp with
aarch64-linux, we run into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, compdir_missing__ldir_missing__file_basename () at \
tmp-dw2-dir-file-name.c:999^M
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \
compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
compdir_missing__ldir_missing__file_basename
...
The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
address 0x400608 starts at a line entry:
...
CU: tmp-dw2-dir-file-name.c:
File name Line number Starting address View Stmt
tmp-dw2-dir-file-name.c 999 0x400608 x
tmp-dw2-dir-file-name.c 1000 0x40062c x
tmp-dw2-dir-file-name.c - 0x40062c
...
and therefore the breakpoint is printed without instruction address.
In contrast, for x86_64-linux, we have the breakpoint printed with instruction
address:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x004004c1 in compdir_missing__ldir_missing__file_basename () \
at tmp-dw2-dir-file-name.c:999^M
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
compdir_missing__ldir_missing__file_basename
...
The breakpoint set at compdir_missing__ldir_missing__file_basename_label,
address 0x004004c1 doesn't start at a line entry:
...
CU: tmp-dw2-dir-file-name.c:
File name Line number Starting address View Stmt
tmp-dw2-dir-file-name.c 999 0x4004bd x
tmp-dw2-dir-file-name.c 1000 0x4004d3 x
tmp-dw2-dir-file-name.c - 0x4004d3
...
Fix this by:
- unifying behaviour between the archs by adding an explicit line number entry
for the address compdir_missing__ldir_missing__file_basename_label, making
the FAIL reproducible on x86_64-linux.
- expecting the breakpoint to be printed without instruction address.
Tested on x86_64-linux and aarch64-linux.
|
|
gdb.base/so-impl-ld.exp was setup assuming that the compiler would add
epilogue information and that GDB would stop in the } line. This would
make clang tests fail like so:
step^M
solib_main (arg=10000) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/solib1.c:7^M
7|__ return arg*arg;|__|___/* HERE */^M
(gdb) PASS: gdb.base/so-impl-ld.exp: step into solib call
next^M
main () at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.c:22^M
22|_ return 0;^M
(gdb) FAIL: gdb.base/so-impl-ld.exp: step in solib call
next^M
0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.base/so-impl-ld.exp: step out of solib call
This patch changes it so solib_main has 2 lines where GDB can stop
regardless of compiler choices, and updates the exp file to
generically deal with unknown number of steps until leaving that
function.
|
|
Currently, GDB's testsuite uses a set amount of step commands to exit
functions. This is a problem if a compiler emits different epilogue
information from gcc, or emits no epilogue information at all. It was
most noticeable if Clang was used to test GDB.
To fix this unreliability, this commit introduces a new proc that will
step the inferior until it is stopped at a line that matches the given
regexp, or until it steps too many times - defined as an optional
argument. If the line is found, it shows up as a single PASS in the
test, and if the line is not found, a single FAIL is emitted.
This patch only introduces this proc, but does not add it to any
existing tests, these will be introduced in the following commit.
|
|
Not all compilers add stderr debug information when compiling a
program. Clang, for instance, prefers to add nothing from standard
libraries and let an external debug package have this information.
Because of this, gdb.base/dprintf.exp was failing when GDB attempted to
use dprintf as a call to fprintf(stderrr, ...), like this:
(gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call
continue
Continuing.
kickoff 1234
also to stderr 1234
'stderr' has unknown type; cast it to its declared type
(gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout)
To avoid this false positive, we explicitly test to see if
the compiler has added information about stderr at all, and abort
testing dprintf as an fprintf call if it is unavailable.
|
|
clang doesn't add encoding to the name of complex variables, only says
that the type name is complex, making the relevant tests fail.
This patch adds the xfails to the tests that expect the variable name to
include it.
|
|
When running gdb.base/call-ar-st.exp against Clang, we see one FAIL,
like so:
print_all_arrays (array_i=<main.integer_array>, array_c=<main.char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa
ZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<main.float_array>, array_d=<main.double_array>) at ../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
274 print_int_array(array_i); /* -step1- */
(gdb) FAIL: gdb.base/call-ar-st.exp: step inside print_all_arrays
With GCC we instead see:
print_all_arrays (array_i=<integer_array>, array_c=<char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<float_array>, array_d=<double_array>) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
274 print_int_array(array_i); /* -step1- */
(gdb) PASS: gdb.base/call-ar-st.exp: step inside print_all_arrays
The difference is that with Clang we get:
array_i=<main.integer_array>, ...
instead of
array_i = <integer_array>, ...
These symbols are local static variables, and "main" is the name of
the function they are defined in. GCC instead appends a sequence
number to the linkage name:
$ nm -A call-ar-st.gcc | grep integer_
call-ar-st/call-ar-st:00000000000061a0 b integer_array.3968
$ nm -A call-ar-st.clang | grep integer_
call-ar-st:00000000004061a0 b main.integer_array
This commit changes the testcase to accept both outputs, as they are
functionally identical.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Iaf2ccdb9d5996e0268ed12f595a6e04b368bfcb4
|
|
Clang was optimizing global_var away because it was not being used
anywhere. this commit fixes that by adding the attribute used it.
|
|
The test specifically mentions that it doesn't care where the program
stops, however it was still testing for a specific location. The clang
compiler emits different line information for epilogue, so GDB reports a
different stopping location, depending on the used compiler. With this
patch the test works even with clang.
|
|
Clang organizes the variables differently to gcc in the original version
of this code, leading to the following differences when testing
p (int*) &dataglobal + 1
gcc:
$16 = (int *) 0x404034 <datalocal>
clang:
$16 = (int *) 0x404034 <dataglobal8>
However, since the important part of this test doesn't seem to be which
symbol is linked, but rather if GDB is correctly increasing the
address. This test was changed to actually measure address changes,
instead of assuming the ordering and naming of symbols.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
|
|
The .gdb_index variant of commit d878bb39e41 ("[gdb/symtab] Support
.debug_names section with TUs in .debug_info").
Tested on x86_64-linux.
|
|
In commit cd919f5533c ("[gdb/testsuite] Fix
gdb.dwarf2/dw2-dir-file-name.exp"), I made gdb.dwarf2/dw2-dir-file-name.exp
independent of prologue analyzers, using this change:
...
- gdb_breakpoint $func
+ gdb_breakpoint *$func
...
That however caused a regression on ppc64le. For PowerPC, as described in the
ELFv2 ABI, a function can have a global and local entry point.
Setting a breakpoint on *$func effectively creates a breakpoint for the global
entry point, so if the function is entered through the local entry point, the
breakpoint doesn't trigger.
Fix this by reverting commit cd919f5533c, and setting the breakpoint on
${func}_label instead.
Tested on x86_64-linux and ppc64le-linux.
|
|
When running test-case gdb.dwarf2/dw2-dir-file-name.exp with clang, we run
into:
...
(gdb) break *compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400580^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x0000000000400580 in \
compdir_missing.ldir_missing.file_basename ()^M
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: \
compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
compdir_missing__ldir_missing__file_basename
...
The problem is that the test-case uses labels outside functions, which is know
to cause problem with clang, as documented in the comment for proc
function_range.
Fix this by using get_func_info instead.
Tested on x86_64-linux, with both gcc 7.5.0 and clang 13.0.0.
|
|
Currently, the test-case contained in this patch fails:
...
(gdb) p (int) foo ()^M
Invalid cast.^M
(gdb) FAIL: gdb.dwarf2/dw2-unspecified-type.exp: p (int) foo ()
...
because DW_TAG_unspecified_type is translated as void.
There's some code in read_unspecified_type that marks the type as stub, but
that's only active for ada:
...
if (cu->lang () == language_ada)
type->set_is_stub (true);
...
Fix this by:
- marking the type as a stub for all languages, and
- handling the stub return type case in call_function_by_hand_dummy.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29558
|
|
This test generates 48 failures on Power 9 when testing with HW watchpoints
enabled. Note HW watchpoint support is disabled on Power 9 due to a HW bug.
The skip_hw_watchpoint_tests proc must be used to correctly determine
if the processor supports HW watchpoints.
This patch replaces the [target_info exists gdb,no_hardware_watchpoints]
with the skip_hw_watchpoint_tests check.
This patch was tested on Power 9, Power 10 and X86-64 with no regressions.
|
|
On aarch64-linux, with gcc 7.5.0, we run into:
...
(gdb) frame^M
#0 callee.increment (val=99.0, val@entry=9.18340949e-41, msg=...) at \
callee.adb:21^M
21 if Val > 200.0 then^M
(gdb) FAIL: gdb.ada/O2_float_param.exp: scenario=all: frame
...
The problem is a GCC bug, filed as "PR98148 - [AArch64] Wrong location
expression for function entry values" (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98148 ).
Xfail the test for aarch64 and gcc 7.
Tested on x86_64-linux and aarch64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29418
|
|
On aarch64-linux, I run into:
...
Breakpoint 2, pck.inspect (obj=0x430eb0 \
<system.pool_global.global_pool_object>, <objL>=0) at pck.adb:17^M
17 procedure Inspect (Obj: access Top_T'Class) is^M
(gdb) FAIL: gdb.ada/access_tagged_param.exp: continue
...
while on x86_64-linux, I see:
...
Breakpoint 2, pck.inspect (obj=0x62b2a0, <objL>=2) at pck.adb:19^M
19 null;^M
(gdb) PASS: gdb.ada/access_tagged_param.exp: continue
...
Note the different line numbers, 17 vs 19.
The difference comes from the gdbarch_skip_prologue implementation.
The amd64_skip_prologue implementation doesn't use gcc line numbers, and falls
back to the architecture-specific prologue analyzer, which correctly skips
past the prologue, to address 0x4022f7:
...
00000000004022ec <pck__inspect>:
4022ec: 55 push %rbp
4022ed: 48 89 e5 mov %rsp,%rbp
4022f0: 48 89 7d f8 mov %rdi,-0x8(%rbp)
4022f4: 89 75 f4 mov %esi,-0xc(%rbp)
4022f7: 90 nop
4022f8: 90 nop
4022f9: 5d pop %rbp
4022fa: c3 ret
...
The aarch64_skip_prologue implementation does use gcc line numbers, which are:
...
File name Line number Starting address View Stmt
pck.adb 17 0x402580 x
pck.adb 17 0x402580 1 x
pck.adb 19 0x40258c x
pck.adb 20 0x402590 x
...
and which are represented like this internally in gdb:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
0 17 0x0000000000402580 Y
1 17 0x0000000000402580 Y
2 19 0x000000000040258c Y
3 20 0x0000000000402590 Y
4 END 0x00000000004025a0 Y
...
The second entry is interpreted as end-of-prologue, so 0x402580 is used, while
the actual end of the prologue is at 0x40258c:
...
0000000000402580 <pck__inspect>:
402580: d10043ff sub sp, sp, #0x10
402584: f90007e0 str x0, [sp, #8]
402588: b90007e1 str w1, [sp, #4]
40258c: d503201f nop
402590: d503201f nop
402594: 910043ff add sp, sp, #0x10
402598: d65f03c0 ret
40259c: d503201f nop
...
Note that the architecture-specific prologue analyzer would have gotten this
right:
...
(gdb) p /x aarch64_analyze_prologue (gdbarch, pc, pc + 128, 0)
$2 = 0x40258c
...
Fix the FAIL by making the test-case more robust against problems in prologue
skipping, by setting the breakpoint on line 19 instead.
Likewise in a few similar test-cases.
Tested on x86_64-linux and aarch64-linux.
|
|
On openSUSE Tumbleweed (using glibc 2.36), I run into:
...
(gdb) print /d (int) munmap (4198400, 4096)^M
Invalid cast.^M
(gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: \
get integer valueof "(int) munmap (4198400, 4096)"
...
The problem is that after starting the executable, the symbol has type
"void (*) (void)":
...
(gdb) p munmap
$1 = {<text variable, no debug info>} 0x401030 <munmap@plt>
(gdb) start
...
(gdb) p munmap
$2 = {void (void)} 0x7ffff7feb9a0 <__GI_munmap>
...
which causes the "Invalid cast" error.
Looking at the debug info for glibc for symbol __GI_munmap:
...
<0><189683>: Abbrev Number: 1 (DW_TAG_compile_unit)
<189691> DW_AT_name : ../sysdeps/unix/syscall-template.S
<189699> DW_AT_producer : GNU AS 2.39.0
<1><1896ae>: Abbrev Number: 2 (DW_TAG_subprogram)
<1896af> DW_AT_name : __GI___munmap
<1896b3> DW_AT_external : 1
<1896b4> DW_AT_low_pc : 0x10cad0
<1896bc> DW_AT_high_pc : 37
...
that's probably caused by this bit (or similar bits for other munmap aliases).
This is fixed in gas on trunk by commit 5578fbf672e ("GAS: Add a return type
tag to DWARF DIEs generated for function symbols").
Work around this (for say gas 2.39) by explicitly specifying the prototype for
munmap.
Likewise for getpid in a couple of other test-cases.
Tested on x86_64-linux.
|
|
When running test-case gdb.cp/cpexprs-debug-types.exp on target board
cc-with-debug-names/gdb:debug_flags=-gdwarf-5, we get an executable with
a .debug_names section, but no .debug_types section. For dwarf-5, the TUs
are no longer put in a separate unit, but instead they're put in the
.debug_info section.
When loading the executable, the .debug_names section is silently ignored
because of this check in dwarf2_read_debug_names:
...
if (map->tu_count != 0)
{
/* We can only handle a single .debug_types when we have an
index. */
if (per_bfd->types.size () != 1)
return false;
...
which triggers because per_bfd->types.size () == 0.
The intention of the check is to make sure we don't have more that one
.debug_types section, as can happen in a object file (see PR12984):
...
$ grep "\.debug_types" 11.s
.section .debug_types,"G",@progbits,wt.75c042c23a9a07ee,comdat
.section .debug_types,"G",@progbits,wt.c59c413bf50a4607,comdat
...
Fix this by:
- changing the check condition to "per_bfd->types.size () > 1", and
- handling per_bfd->types.size () == 0.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29385
|
|
Add test-case gdb.dwarf2/debug-names-bad-cu-index.exp, a regression test for
commit 2fe9a3c41fa ("[gdb/symtab] Fix bad compile unit index complaint").
Tested on x86_64-linux.
|
|
Add a test-case gdb.dwarf2/debug-names-tu.exp, that uses the dwarf assembler
to specify a .debug_names index with the TU list referring to a TU from the
.debug_types section.
This is intended to produce something similar to:
...
$ gcc -g -fdebug-types-section ~/hello.c -gdwarf-4
$ gdb-add-index -dwarf-5 a.out
...
Tested on x86_64-linux.
|
|
PR mi/10347 points out that using interpreter-exec inside of a
"define" command will crash gdb. The bug here is that
gdb_setup_readline doesn't check for the case where instream==nullptr.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10347
|
|
PR mi/15811 points out that "source"ing a file that uses
interpreter-exec will put gdb in a weird state, where the CLI stops
working. The bug is that tui_interp::suspend does not unregister the
event file descriptor.
The test case is from Andrew Burgess.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15811
|
|
First, some background on the RISC-V registers fflags, frm, and fcsr.
These three registers all relate to the floating-point status and
control mechanism on RISC-V. The fcsr is the floatint-point control
status register, and consists of two parts, the flags (bits 0 to 4)
and the rounding-mode (bits 5 to 7).
The fcsr register is just one of many control/status registers (or
CSRs) available on RISC-V. The fflags and frm registers are also
CSRs. These CSRs are aliases for the relevant parts of the fcsr
register. So fflags is an alias for bits 0 to 4 of fcsr, and frm is
an alias for bits 5 to 7 of fcsr.
This means that a user can change the floating-point rounding mode
either, by writing a complete new value into fcsr, or by writing just
the rounding mode into frm.
How this impacts on GDB is like this: a target description could,
legitimately include all three registers, fcsr, fflags, and frm. The
QEMU target currently does this, and this makes sense. The target is
emulating the complete system, and has all three CSRs available, so
why not tell GDB about this.
In contrast, the RISC-V native Linux target only has access to the
fcsr. This is because the ptrace data structure that the kernel uses
for reading and writing floating point state only contains a copy of
the fcsr, after all, this one field really contains both the fflags
and frm fields, so why carry around duplicate data.
So, we might expect that the target description for the RISC-V native
Linux GDB would only contain the fcsr register. Unfortunately, this
is not the case. The RISC-V native Linux target uses GDB's builtin
target descriptions by calling riscv_lookup_target_description, this
will then add an fpu feature from gdb/features/riscv, either
32bit-fpu.xml or 64bit-fpu.xml. The problem, is that these features
include an entry for fcsr, fflags, and frm. This means that GDB
expects the target to handle reading and writing these registers. And
the RISC-V native Linux target currently doesn't.
In riscv_linux_nat_target::store_registers and
riscv_linux_nat_target::fetch_registers only the fcsr register is
handled, this means that, for RISC-V native Linux, the fflags and frm
registers always show up as <unavailable> - they are present in the
target description, but the target doesn't know how to access the
registers.
A final complication relating to these floating pointer CSRs is which
target description feature the registers appear in.
These registers are CSRs, so it would seem sensible that these
registers should appear in the CSR target description feature.
However, when I first added RISC-V target description support, I was
using a RISC-V simulator that didn't support any CSRs other than the
floating point related ones. This simulator bundled all the float
related CSRs into the fpu target feature. This didn't feel completely
unreasonable to me, and so I had GDB check for these registers in
either target feature.
In this commit I make some changes relating to how GDB handles the
three floating point CSR:
1. Remove fflags and frm from 32bit-fpu.xml and 64bit-fpu.xml. This
means that the default RISC-V target description (which RISC-V native
FreeBSD), and the target descriptions created for RISC-V native Linux,
will not include these registers. There's nothing stopping some other
target (e.g. QEMU) from continuing to include all three of these CSRs,
the code in riscv-tdep.c continues to check for all three of these
registers, and will handle them correctly if they are present.
2. If a target supplied fcsr, but does not supply fflags and/or frm,
then RISC-V GDB will now create two pseudo registers in order to
emulate the two missing CSRs. These new pseudo-registers do the
obvious thing of just reading and writing the fcsr register.
3. With the new pseudo-registers we can no longer make use of the GDB
register numbers RISCV_CSR_FFLAGS_REGNUM and RISCV_CSR_FRM_REGNUM.
These will be the numbers used if the target supplies the registers in
its target description, but, if GDB falls back to using
pseudo-registers, then new, unique numbers will be used. To handle
this I've added riscv_gdbarch_tdep::fflags_regnum and
riscv_gdbarch_tdep::frm_regnum, I've then updated the RISC-V code to
compare against these fields.
When adding the pseudo-register support, it is important that the
pseudo-register numbers are calculated after the call to
tdesc_use_registers. This is because we don't know the total number
of physical registers until after this call, and the psuedo-register
numbers must follow on from the real (target supplied) registers.
I've updated some tests to include more testing of the fflags and frm
registers, as well as adding a new test.
|
|
On RISC-V the FCSR (float control/status register) is split into two
parts, FFLAGS (the flags) and FRM (the rounding mode). Both of these
two fields are part of the FCSR register, but can also be accessed as
separate registers in their own right. And so, we have three separate
registers, $fflags, $frm, and $fcsr, with the last of these being the
combination of the first two.
Here's how the bits of FCSR are split between FRM and FFLAGS:
,--------- FFLAGS
|---|
76543210 <----- FCSR
|-|
'--------------FRM
Here's how GDB currently displays these registers:
(gdb) info registers $fflags $frm $fcsr
fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]
fcsr 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]
Notice the 'RD' field which is present in both $fflags and $fcsr.
This field contains the value of the FRM field, which makes sense when
displaying the $fcsr, but makes no sense when displaying $fflags, as
the $fflags doesn't include the FRM field.
Additionally, the $fcsr already includes an FRM field, so the
information in 'RD' is duplicated. Consider this:
(gdb) set $frm = 0x3
(gdb) info registers $fflags $frm $fcsr │
fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x3 FRM:3 [RUP (Round up towards +INF)]
fcsr 0x60 RD:3 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]
See how the 'RD' field in $fflags still displays 0, while the 'RD' and
'FRM' fields in $fcsr show the same information.
The first change I propose in this commit is to remove the 'RD'
field. After this change the output now looks like this:
(gdb) info registers $fflags $frm $fcsr
fflags 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]
fcsr 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]
Next, I spotted that the text that goes along with the 'FRM' field was
not wrapped in the i18n markers for internationalisation, so I added
those.
Next, I spotted that:
(gdb) set $frm=0x7
(gdb) info registers $fflags $frm $fcsr
fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x7 FRM:3 [RUP (Round up towards +INF)]
fcsr 0xe0 RD:7 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]
Notice that despite being a 3-bit field, FRM masks to 2-bits.
Checking the manual I can see that the FRM field is 3-bits, and is
defined for all 8 values. That GDB masks to 2-bits is just a bug I
think, so I've fixed this.
Finally, the 'FRM' text for value 0x7 is wrong. Currently we use the
text 'dynamic rounding mode' for value 0x7. However, this is not
really correct.
A RISC-V instruction can either encode the rounding mode within the
instruction, or a RISC-V instruction can choose to use a global,
dynamic rounding mode.
So, for the rounding-mode field of an _instruction_ the value 0x7
indicates "dynamic round mode", the instruction should defer to the
rounding mode held in the FRM field of the $fcsr.
But it makes no sense for the FRM of $fcsr to itself be set to
0x7 (dynamic rounding mode), and indeed, section 11.2, "Floating-Point
Control and Status Register" of the RISC-V manual, says that a value
of 0x7 in the $fcsr FRM field is invalid, and if an instruction has
_its_ round-mode set to dynamic, and the FRM field is also set to 0x7,
then an illegal instruction exception is raised.
And so, I propose changing the text for value 0x7 of the FRM field to
be "INVALID[7] (Dynamic rounding mode)". We already use the text
"INVALID[5]" and "INVALID[6]" for the two other invalid fields,
however, I think adding the extra "Dynamic round mode" hint might be
helpful.
I've added a new test that uses 'info registers' to check what GDB
prints for the three registers related to this patch. There is one
slight oddity with this test - for the fflags and frm registers, the
test accepts both the "normal" output (as described above), but also
allows these registers to be reported as '<unavailable>'.
The reason why I accept <unavailable> is that currently, the RISC-V,
native Linux target advertises these registers in its target
description, but then doesn't support reading or writing of these
registers, this results in the registers being reported as
unavailable.
A later patch in this series will address this issue, and will remove
this check for <unavailable>.
|
|
The following GDB behavior was also reported as a GDB bug in
https://sourceware.org/bugzilla/show_bug.cgi?id=28396
I will reiterate the problem a bit and give some more information here.
This patch closes the above mentioned bug.
The DWARF 5 standard 2.23 'Template Parameters' reads:
A template type parameter is represented by a debugging information
entry with the tag DW_TAG_template_type_parameter. A template value
parameter is represented by a debugging information entry with the tag
DW_TAG_template_value_parameter. The actual template parameter entries
appear in the same order as the corresponding template formal
parameter declarations in the source progam.
A type or value parameter entry may have a DW_AT_name attribute, whose
value is a null-terminated string containing the name of the
corresponding formal parameter.
So the DW_AT_name attribute for DW_TAG_template_type_parameter and
DW_TAG_template_value_parameter is optional.
Within GDB, creating a new symbol from some read DIE usually requires the
presence of a DW_AT_name for the DIE (an exception here is the case of
unnamed namespaces or the existence of a linkage name).
This patch makes the presence of the DW_AT_name for template value/type
tags optional, similar to the unnamed namespaces.
For unnamed namespaces dwarf2_name simply returns the constant string
CP_ANONYMOUS_NAMESPACE_STR '(anonymous namespace)'. For template tags a
case was added to the switch statement calling the
unnamed_template_tag_name helper. Within the scope of parent which
the template parameter is a child of, the helper counts the position
of the template tag within the unnamed template tags and returns
'<unnamedNUMBER>' where NUMBER is its position. This way we end up with
unique names within the respective scope of the function/class/struct
(these are the only currenltly supported template kinds within GDB and
usually the compilers) where we discovered the template tags in.
While I do not know of a way to bring GCC to emit template tags without
names there is one for clang/icpx. Consider the following example
template<typename A, typename B, typename C>
class Foo {};
template<typename, typename B, typename>
class Foo;
int main () {
Foo<double, int, float> f;
return 0;
}
The forward declaration for 'Foo' with the missing template type names
'A' and 'C' makes clang emit a bunch of template tags without names:
...
<2><43>: Abbrev Number: 3 (DW_TAG_variable)
<44> DW_AT_location : 2 byte block: 91 78 (DW_OP_fbreg: -8)
<47> DW_AT_name : (indirect string, offset: 0x63): f
<4b> DW_AT_decl_file : 1
<4c> DW_AT_decl_line : 8
<4d> DW_AT_type : <0x59>
...
<1><59>: Abbrev Number: 5 (DW_TAG_class_type)
<5a> DW_AT_calling_convention: 5 (pass by value)
<5b> DW_AT_name : (indirect string, offset: 0x74): Foo<double, int, float>
<5f> DW_AT_byte_size : 1
<60> DW_AT_decl_file : 1
<61> DW_AT_decl_line : 2
<2><62>: Abbrev Number: 6 (DW_TAG_template_type_param)
<63> DW_AT_type : <0x76>
<2><67>: Abbrev Number: 7 (DW_TAG_template_type_param)
<68> DW_AT_type : <0x52>
<6c> DW_AT_name : (indirect string, offset: 0x6c): B
<2><70>: Abbrev Number: 6 (DW_TAG_template_type_param)
<71> DW_AT_type : <0x7d>
...
Befor this patch, GDB would not create any symbols for the read template
tag DIEs and thus lose knowledge about them. Breaking at the return
statement and printing f's type would read
(gdb) ptype f
type = class Foo<double, int, float> [with B = int] {
<no data fields>
}
After this patch GDB does generate symbols from the DWARF (with their
artificial names:
(gdb) ptype f
type = class Foo<double, int, float> [with <unnamed0> = double, B = int,
<unnamed1> = float] {
<no data fields>
}
The same principle theoretically applies to template functions. Also
here, GDB would not record unnamed template TAGs but I know of no visual
way to trigger and test this changed behavior. Template functions do
not emit a '[with...]' list and their name generation also does not
suffer from template tags without names. GDB does not check whether or
not a template tag has a name in 'dwarf2_compute_name' and thus, the
names of the template functions are created independently of whether or
not the template TAGs have a DW_TAT_name attribute. A testcase has
been added in the gdb.dwarf2 for template classes and structs.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28396
|
|
When writing a dwarf testcase for some C++ code I wanted to use the
MACRO_AT_range which in turn uses the function_range proc in dwarf.exp
to extract the bounds of 'main'.
However, the macro failed as GDB prints the C++ 'main' with its
arguments as 'main(int, char**)' or 'main()'.
The reason for this is that in read.c::dwarf2_compute_name we call
c_type_print_args on C++ functions and append their arguments to the
function name. This happens to all C++ functions, but is only visible
when the function doesn't have a linkage name.
An example might make this more clear. Given the following code
>> cat c.cpp
int foo (int a, float b)
{
return 0;
}
int main (int argc, char **argv)
{
return 0;
}
which is legal in both languages, C and C++, and compiling it with
e.g. clang or gcc will make the disassemble command look like:
>> clang --version
clang version 10.0.0-4ubuntu1
...
>> clang -O0 -g ./c.cpp
>> gdb -q ./a.out -ex "start"
...
(gdb) disassemble main
Dump of assembler code for function main(int, char**):
0x0000000000401120 <+0>: push %rbp
0x0000000000401121 <+1>: mov %rsp,%rbp
...
0x0000000000401135 <+21>: ret
End of assembler dump.
(gdb) disassemble foo
Dump of assembler code for function _Z3fooif:
0x0000000000401110 <+0>: push %rbp
0x0000000000401111 <+1>: mov %rsp,%rbp
...
0x000000000040111f <+15>: ret
End of assembler dump.
Note, that main is emitted with its arguments while for foo the linkage
name is being printed, as also visible in its DWARF:
>> objdump ./a.out --dwarf=info | grep "foo" -A3 -B3
<2b> DW_AT_low_pc : 0x401110
<33> DW_AT_high_pc : 0x10
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_linkage_name: (indirect string, offset: 0x39): _Z3fooif
<3d> DW_AT_name : (indirect string, offset: 0x42): foo
<41> DW_AT_decl_file : 1
<42> DW_AT_decl_line : 1
<43> DW_AT_type : <0x9a>
Now, let's rename the C++ file and compile it as C:
>> mv c.cpp c.c
>> clang -O0 -g ./c.c
>> gdb -q ./a.out -ex "start'
...
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000401120 <+0>: push %rbp
0x0000000000401121 <+1>: mov %rsp,%rbp
...
0x0000000000401135 <+21>: ret
End of assembler dump.
(gdb) disassemble foo
Dump of assembler code for function foo:
0x0000000000401110 <+0>: push %rbp
0x0000000000401111 <+1>: mov %rsp,%rbp
...
0x000000000040111f <+15>: ret
End of assembler dump.
Note, for foo we did not get a linkage name emitted in DWARF, so
it is printed by its name:
>> objdump --dwarf=info ./a.out | grep foo -A3 -B3
<2b> DW_AT_low_pc : 0x401110
<33> DW_AT_high_pc : 0x10
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_name : (indirect string, offset: 0x37): foo
<3d> DW_AT_decl_file : 1
<3e> DW_AT_decl_line : 1
<3f> DW_AT_prototyped : 1
To make the macro and proc work with C++ as well, an optional argument
list was added to the regex matching the function name in the
disassemble command in function_range. This does not change any used
behavior as currently, there exists no C++ test using the proc
function_range.
Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
|
