| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Following on from the previous commit, this commit fixes the two KFAIL
in gdb.base/sysroot-debug-lookup.exp when not using the
native-extended-gdbserver board.
The failures in this test, when using the 'unix' board, are logged as
bug PR gdb/31804. The problem appears to be caused by the use of the
child_path function in find_separate_debug_file.
What happens on the 'unix' board is that the file is specified to GDB
with a target: prefix, however GDB spots that the target filesystem is
local to GDB and so opens the file without a target: prefix. When we
call into find_separate_debug_file the DIR and CANON_DIR arguments,
which are computed from the objfile_name() no longer have a target:
prefix.
However, in this test if the file was opened with a target: prefix,
then the sysroot also has a target: prefix. When child_path is called
it looks for a common prefix between CANON_DIR (from the objfile_name)
and the sysroot. However, the sysroot still has the target: prefix,
which means the child_path() call fails and returns nullptr.
What I think we need to do is this: if the sysroot has a target:
prefix, and the target filesystem is local to GDB, then we should
strip the target: prefix from the sysroot, just as we do when opening
a file (see gdb_bfd_open in gdb_bfd.c).
Now, when we make the child_path() call neither the sysroot nor
CANON_DIR will have a target: prefix, the child_path() call will
succeed, and GDB will correctly find the debug information.
There is just one remaining issue, the last path we look in when
searching for debug information is built by starting with the sysroot,
then adding the debug directory, see this line:
debugfile = path_join (target_prefix_str, root.c_str (),
debugdir.get (), base_path, debuglink);
The target_prefix_str is set to target: if DIR has a target: prefix,
and DIR should have a target: prefix if the file we're looking for was
opened with a target: prefix. However, in our case the file was in a
local filesystem so GDB stripped the prefix off.
The sysroot however, does have the target: prefix, and the test is
expecting to see GDB look within a file with the target: prefix.
Given that the above line is about looking within a sub-directory of
the sysroot, I think we should not be stripping the target: prefix off
the sysroot path (as we do when building ROOT), instead, we should, in
this case, not use TARGET_PREFIX_STR, and instead just use GDB's
sysroot as it is (in this case with the target: prefix).
With these fixes in place I now see no failures when using the 'unix',
'native-gdbserver', or 'native-extended-gdbserver' boards with this
test, and the KFAILs can be removed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
|
|
I spotted that the gdb.base/sysroot-debug-lookup.exp test that I added
recently actually had a KPASS when run with the
native-extended-gdbserver board. This was an oversight when adding
the test.
The failures in this test, when using the 'unix' board, are logged as
bug PR gdb/31804. The problem appears to be caused by the use of the
child_path function in find_separate_debug_file.
What happens on the 'unix' board is that the file is specified to GDB
with a target: prefix, however GDB spots that the target filesystem is
local to GDB and so opens the file without a target: prefix. When we
call into find_separate_debug_file the DIR and CANON_DIR arguments,
which are computed from the objfile_name() no longer have a target:
prefix.
However, in this test if the file was opened with a target: prefix,
then the sysroot also has a target: prefix. When child_path is called
it looks for a common prefix between CANON_DIR (from the objfile_name)
and the sysroot. However, the sysroot still has the target: prefix,
which means the child_path() call fails and returns nullptr.
What happens in the native-extended-gdbserver case is that GDB doesn't
see the target filesystem as local. Now the filename retains the
target: prefix, which means that in the child_path() call both the
sysroot and the CANON_DIR have a target: prefix, and so the
child_path() call succeeds. This allows GDB to progress, try some
additional paths, and then find the debug information.
So, this commit changes gdb.base/sysroot-debug-lookup.exp to expect
the test to succeed when using the native-extended-gdbserver protocol.
This leaves one KFAIL when using the native-extended-gdbserver board,
we find the debug information but (apparently) find it in the wrong
file. What's happening is that when GDB builds the filename for the
debug information we end up with a '//' string as a directory
separator, the test regexp only expects a single separator.
Instead of just fixing the test regexp, I've updated the path_join
function in gdbsupport/pathstuff.{cc,h} to allow for absolute paths to
appear in the argument list after the first argument. This means it's
now possible to do this:
auto result = path_join ("/a/b/c", "/d/e/f");
gdb_assert (result == "/a/b/c/d/e/f");
Additionally I've changed path_join so that it avoids adding
unnecessary directory separators. In the above case when the two
paths were joined GDB only added a single separator between 'c' and
'd'. But additionally, if we did this:
auto result = path_join ("/a/b/c/", "/d/e/f");
gdb_assert (result == "/a/b/c/d/e/f");
We'd still only get a single separator.
With these changes to path_join I can now make use of this function in
find_separate_debug_file. With this done I now have no KFAIL when
using the native-extended-gdbserver board.
After this commit we still have 2 KFAIL when not using the
native-gdbserver and unix boards, these will be addressed in the next
commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
Usually with test-case gdb.python/py-progspace-events.exp I get:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 4116] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M
28 { /* Nothing. */ }^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
step^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabf4f850>^M
do_parent_stuff () at py-progspace-events.c:41^M
41 ++global_var;^M
(gdb) PASS: gdb.python/py-progspace-events.exp: step
...
But occasionally I run into the following FAIL:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
(gdb) FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout)
...
This is caused by a race between the handling of an event, and the
"inferior 1" command.
In the passing case, the event is handled first. During which prune_inferiors
is called, but it can't remove inferior 2, because it's still the current one.
In the failing case, the "inferior 1" command is handled first. Then during
handling of the event, prune_inferiors is called, and it can remove inferior 2
because it's no longer the current one.
This looks like a test-case issue to me, but ISTM that we can do better: by
calling prune_inferiors asap, at the end of the "inferior 1" command, we
stabilize the moment when the inferior is removed:
...
(gdb) inferior 1^M
[Switching to inferior 1 [process 5199] (py-progspace-events)]^M
[Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M
28 { /* Nothing. */ }^M
FreeProgspaceEvent: <gdb.Progspace object at 0xabaf03a0>^M
(gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1
...
This also allows us to simplify the test-case by removing the step command,
which is no longer required to trigger the pruning of the inferior.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR gdb/31440
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440
|
|
The relatively new "globals" scope code in DAP has a fairly obvious
bug -- the fetch_one_child method should return a tuple with two
elements, but instead just returns the variable's value.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into:
...
(gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada
print pck.fp1_var^M
$1 = 0.3125^M
(gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var
...
The problem is that the thumb prologue analyzer overshoot, setting the
breakpoint for main after line 49:
...
46 int
47 main (void)
48 {
49 pck__fp1_var++;
...
and consequently we see the value of pck.fp1_var after line 49 instead of
before line 49. This is PR tdep/31981.
Work around this by removing line 49 and all similar subsequent lines, which
turn out to be dead code.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested on arm-linux.
|
|
On arm-linux I run into:
...
(gdb) p *kernel_user_helper_version^M
Cannot access memory at address 0xffff0ffc^M
(gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version
...
What the test-case is trying to do, is to access a special address in the arm
linux kernel [1] using ptrace, which doesn't seem to work.
This is with kernel version 6.1.55. Perhaps this used to work, but the kernel
was modified to be more strict with respect to access to this special address.
Fix this by making the inferior access that special address instead.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR testsuite/32070
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070
[1] https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt
|
|
My previous patch
commit 8958aefd34200c8d2cd6e81bba32198468789c62 (HEAD)
Author: Felix Willgerodt <felix.willgerodt@intel.com>
Date: Mon Feb 25 15:30:29 2019 +0100
python: Add clear() to gdb.Record.
exposed a clear function for btrace data in python and added some tests
for it. That caused a regression (PR 32086) when recording with bts.
This is reproducible even without my patch, when adding
"maintenance btrace clear" to the test.
When comparing the instructions that get recorded in both cases, the traces
are almost identical, just that the first 3 instructions are missing.
Before clear:
(gdb) record instruction-history 1,100
1 0x0000555555555163 <main+12>: movl $0x0,-0x4(%rbp)
2 0x000055555555516a <main+19>: movl $0x0,-0x8(%rbp)
3 0x0000555555555171 <main+26>: jmp 0x555555555184 <main+45>
4 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
5 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
6 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
7 0x0000555555555176 <main+31>: mov %eax,%edi
...
After clear:
(gdb) record instruction-history 1,100
1 0x0000555555555184 <main+45>: cmpl $0x63,-0x4(%rbp)
2 0x0000555555555188 <main+49>: jle 0x555555555173 <main+28>
3 0x0000555555555173 <main+28>: mov -0x8(%rbp),%eax
4 0x0000555555555176 <main+31>: mov %eax,%edi
...
The GDB manual describes this behaviour already:
maint btrace clear
Discard the branch trace data. The data will be fetched anew and
the branch trace will be recomputed when needed.
This implicitly truncates the branch trace to a single branch trace
buffer. When updating branch trace incrementally, the branch trace
available to GDB may be bigger than a single branch trace buffer.
The test with BTS is updating the recorded trace incrementally. After the
clear, the buffer of raw trace data available is not enough to recompute the
whole trace as it was before the clear(), and the first 3 instructions are
missing.
As increasing the buffer size for BTS didn't help, I propose to fix the test
by moving the testing of clear to the end of the test.
Approved-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086
|
|
A DAP user noticed that breakpoints set by address were never updated
to show their location after the DAP launch request. It turns out
that gdb does not emit the breakpoint-modified event when this sort of
breakpoint is updated.
This patch changes gdb to notify the breakpoint-modified observer when
a breakpoint location's symbol changes. This in turn causes the DAP
event to be emitted.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
While working on earlier patches, I noticed that the DAP C++ exception
test had some strange results in the log. Digging into this, I found
that while the Ada catchpoints emit a "bkptno" field in the MI result,
the C++ ones do not -- but the DAP code was relying on this.
This patch fixes the problem by changing which field is examined, and
then updates the tests to verify this.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
Currently, when a DAP client uses setInstructionBreakpoints, the
resulting breakpoints are created as "verified", even though there is
no symbol file and thus the breakpoint can't possibly have a source
location.
This patch changes the DAP code to assume that all breakpoints are
unverified before launch.
Reviewed-by: Keith Seitz <keiths@redhat.com>
|
|
Call the ptwrite filter function whenever a ptwrite event is decoded.
The returned string is written to the aux_data string table and a
corresponding auxiliary instruction is appended to the function segment.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This function allows to clear the trace data from python, forcing to
re-decode the trace for successive commands.
This will be used in future ptwrite patches, to trigger re-decoding when
the ptwrite filter changes.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
There are a couple of ways that readline wrapping can be disabled:
- using "set horizontal-scroll-mode on" in INPUTRC,
- using a TERM setting like TERM=dumb, and
- building gdb with stub-termcap.
Using a trigger patch in default_gdb_init that adds
"set horizontal-scroll-mode on" to INPUTRC:
...
- setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off"]
+ setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off\nset horizontal-scroll-mode on"]
...
we can easily reproduce a failure in gdb.tui/wrap-line.exp mentioned in
PR testsuite/31201 (which was reported for the stub-termcap case):
...
WARNING: timeout in accept_gdb_output
Screen Dump (size 50 columns x 24 rows, cursor at column 34, row 1):
0 Quit
1 <89012345678901234567890123456789W
2
...
23
FAIL: gdb.tui/wrap-line.exp: width-hard-coded: cli: wrap
...
Fix this by accepting the horizontal-scroll-mode style output. We do
this only when in CLI mode though, when in TUI wrapping works as before
because it doesn't rely on readline.
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201
|
|
Remove the support for the QNX Neutrino OS (tdep and native bits). This
has been unmaintained for years, and we don't have a way to see if it
works (or even builds, for the native parts). Without somebody actively
maintaining it, this is just a burden for developers, especially that
this port does a few weird unique things that require reasoning about
when doing big change.
Support for GDBserver was removed in 2020, commit 613f149a90d6
("gdbserver: remove support for Neutrino").
Change-Id: I4e25ec26ab06636629adebd02ceb161ee31c232d
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
This adds a missing allow_tui_tests guard.
When tui is not enabled this test case does
typically fail:
FAIL: gdb.base/new-ui.exp: do_test_invalid_args: new-ui with tui
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
The 'list' command prints around the 'main' function if the current
source location is not set. The prologue of 'main' is skipped and the
first real line of 'main' is offset by 'lines_to_print - 1'. This is
incorrect, the location should be defaulted to main's prologue without
applying offsets (similar to 'list main'). Printing around the selected
line is then done in 'list_around_line'.
The patch also fixes an issue if the list command is used before the
program is started. For example, with the following code:
26 static void attribute ((used)) ambiguous_fun (void) {}
27
28 static int attribute ((used)) ambiguous_var;
29
30
31
32
33
34
35
36
37
38 int
39 main (void)
40 {
41 return 0;
42 }
GDB offsets the relevant line by 'lines_to_print - 1' and then by another
'lines_to_print / 2' and prints:
(gdb) list
27
28 static int attribute ((used)) ambiguous_var;
29
30
31
32
33
34
35
36
With this patch, GDB correctly prints:
37
38 int
39 main (void)
40 {
41 return 0;
42 }
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Using 'output' to print arrays larger than max-value-size, with only
repeating elements, can cause gdb to crash:
```
$ cat a.c:
char a[1000000];
int main()
{
return a[0];
}
$ gdb -q a
(gdb) print a
$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
(gdb) output a
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
Using 'print' works, because value::record_latest sets the unavailable
bytes of the value when it's added to the value history.
But 'outout' doesn't do that, so the printing tries to access more bytes
than are available.
The original problem in PR32015 was about using 'print' of a dynamic
array in a D program.
Here the crash happens because for 'print' the value was a struct with
length/ptr fields, which is converted in d-valprint.c into an array.
So value::record_latest didn't have a chance to mark the unavailable
bytes in this case.
To make sure the unavailable bytes always match the contents, this fixes
it by marking the unavailable bytes immediately after the contents are
allocated.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Consider the following test-case:
...
$ cat -n test.c
1 int var;
2
3 int
4 foo (void)
5 {
6 var = 1;
7 #include "test.h"
8 }
9
10 int
11 main ()
12 {
13 return foo ();
14 }
$ cat -n test.h
1 return 1;
$ gcc test.c -g
...
When stepping through the test-case, gdb doesn't make it explicit that line 1
is not in test.c:
...
Temporary breakpoint 1, main () at test.c:13
13 return foo ();
(gdb) step
foo () at test.c:6
6 var = 1;
(gdb) n
1 return 1;
(gdb)
8 }
(gdb)
...
which makes it easy to misinterpret the output.
This is with the default "print frame-info" == auto, with documented
behaviour [1]:
...
stepi will switch between source-line and source-and-location depending on the
program counter.
...
What is actually implemented is that source-line is used unless stepping into
or out of a function.
The problem can be worked around by using
"set print frame-info source-and-location", but that's a bit verbose.
Instead, change the behaviour of "print frame-info" == auto to also use
source-and-location when stepping into another file, which gets us:
...
(gdb) n
foo () at test.h:1
1 return 1;
...
Tested on x86_64-linux.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
PR gdb/32011
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32011
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Print-Settings.html#index-set-print-frame_002dinfo
|
|
Thiago Jung Bauermann noticed that gdb.base/list-dot-nodebug was not
actually compiling the test with some debuginfo in the relevant part,
and while fixing I noticed that the base assumption of the "some" case
was wrong, GDB would select some symtab as a default location and the
test would always fail. This fix makes printing the default location
only be tested when there is no debuginfo.
When testing with no debuginfo, if a system had static libc debuginfo,
the test would also fail. To add an extra layer of robustness to the
test, this rewrite also strips any stray debuginfo from the executable.
The test would only fail now if it runs in a system that can't handle
stripped debuginfo and has static debuginfo pre-installed.
Reported-By: Tom de Vries <tdevries@suse.de>
Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The final test of gdb.python/py-framefilter-invalidarg.exp expected that
the the backtrace only printed the source file name. However, when using
clang, gdb will always print the full path to the file, which would
cause the test to fail. This commit introduces a regexp that optionally
matches paths, preprended to the file name, which fixes the clang
failure without introducing gcc failures.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The test gdb.fortran/entry-point.exp already has an XFAIL when trying to
set a breakpoint in mod::mod_foo because gcc puts that subprogram in the
wrong scope in the debug information. Clang's debug information looks
the same as gcc's, so the test to setup the xfail has been extended to
also include clang.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Clang doesn't add build-id information by default, unlike gcc. This
means that tests that rely on build-id being available and don't
explicitly add it to the compilation options will fail with clang.
This commit fixes the fails in gdb.python/py-missing-debug.exp,
gdb.server/remote-read-msgs.exp, gdb.base/coredump-filter-build-id.exp
and gdb.server/solib-list.exp
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
On fedora rawhide, with python 3.13, I run into:
...
(gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M
Python Exception <class 'TypeError'>: \
this function got an unexpected keyword argument 'invalid'^M
Error occurred in Python: \
this function got an unexpected keyword argument 'invalid'^M
(gdb) FAIL: $exp: format_string: lang_c: test_all_common: test_invalid_args: \
a_point_t with option invalid=True
...
A passing version with an older python version looks like:
...
(gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M
Python Exception <class 'TypeError'>: \
'invalid' is an invalid keyword argument for this function^M
Error occurred in Python: \
'invalid' is an invalid keyword argument for this function^M
(gdb) PASS: $exp: format_string: lang_c: test_all_common: test_invalid_args: \
a_point_t with option invalid=True
...
Fix this by accepting the updated error message.
Tested on aarch64-linux.
PR testsuite/31912
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31912
|
|
Fix all trailing-text-in-parentheses duplicates exposed by previous patch.
Tested on x86_64-linux and aarch64-linux.
|
|
When using a duplicate test name:
...
fail foo
fail foo
...
we get:
...
FAIL: $exp: foo
FAIL: $exp: foo
DUPLICATE: $exp: foo
...
But when we do:
...
fail foo
fail "foo (timeout)"
...
we get only:
...
FAIL: $exp: foo
FAIL: $exp: foo (timeout)
...
Trailing text between parentheses prefixed with a space is interpreted as
extra information, and not as part of the test name [1].
Consequently, "foo" and "foo (timeout)" do count as duplicate test names,
which should have been detected. This is PR testsuite/29772.
Fix this in CheckTestNames::_check_duplicates, such that we get:
...
FAIL: $exp: foo
FAIL: $exp: foo (timeout)
DUPLICATE: $exp: foo (timeout)
...
[ One note on the implementation: I used the regexp { \([^()]*\)$}. I don't
know whether that covers all required cases, due to the fact that those are
not unambiguousely specified. It might be possible to reverse-engineer that
information by reading or running the "regression analysis tools" mentioned on
the wiki page [1], but I haven't been able to. Regardless, the current regexp
covers a large amount of cases, which IMO should be sufficient to be
acceptable. ]
Doing so shows many new duplicates in the testsuite.
A significant number of those is due to using a message which is a copy of the
command:
...
gdb_test "print (1)"
...
Fix this by handling those cases using test names "gdb-command<print (1)>" and
"gdb-command<print (2)>.
Fix the remaining duplicates manually (split off as follow-up patch for
readability of this patch).
Tested on x86_64-linux and aarch64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29772
[1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages
|
|
I tried to reproduce a problem in test-case gdb.python/py-disasm.exp on a
s390x machine, but when running with target board unix/-m31 I saw that the
required libraries were missing, so I couldn't generate an executable.
However, I realized that I did have an object file, and the test-case should
mostly also work with an object file.
I've renamed gdb.python/py-disasm.exp to gdb.python/py-disasm.exp.tcl and
included it from two new minimal test-case wrappers:
- gdb.python/py-disasm-exec.exp, and
- gdb.python/py-disasm-obj.exp
where the former uses an executable as before, and the latter uses an object
file.
Using an object file required changing the info.read_memory calls in
gdb.python/py-disasm.py:
...
- info.read_memory(1, -info.address + 2)
+ info.read_memory(1, -info.address - 1)
...
because reading from address 2 succeeds. Using address -1 instead does
generate the expected gdb.MemoryError.
Tested on x86_64-linux.
|
|
When running test-case gdb.fortran/intrinsics.exp on arm-linux, I get:
...
(gdb) p cmplx (4,4,16)^M
/home/linux/gdb/src/gdb/f-lang.c:1002: internal-error: eval_op_f_cmplx: \
Assertion `kind_arg->code () == TYPE_CODE_COMPLEX' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
----- Backtrace -----^M
FAIL: gdb.fortran/intrinsics.exp: p cmplx (4,4,16) (GDB internal error)
...
The problem is that 16-byte floats are unsupported:
...
$ gfortran test.f90
test.f90:2:17:
2 | REAL(kind=16) :: foo = 1
| 1
Error: Kind 16 not supported for type REAL at (1)
...
and consequently we end up with a builtin_real_s16 and builtin_complex_s16 with
code TYPE_CODE_ERROR.
Fix this by bailing out asap when encountering such a type.
Without this patch we're able to do the rather useless:
...
(gdb) ptype real*16
type = real*16
(gdb) ptype real_16
type = real*16
...
but with this patch we get:
...
(gdb) ptype real*16
unsupported kind 16 for type real*4
(gdb) ptype real_16
unsupported type real*16
...
Tested on arm-linux.
PR fortran/30537
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30537
|
|
When running test-case gdb.ada/mi_var_access.exp on arm-linux (debian trixie),
I run into:
...
Expecting: ^(-var-create A_String_Access \* A_String_Access[
]+)?((\^done,name="A_String_Access",numchild="[0-9]+",.*|\^error,msg="Value out of range.".*)[
]+[(]gdb[)]
[ ]*)
-var-create A_String_Access * A_String_Access
^error,msg="Cannot access memory at address 0x4"
(gdb)
FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output)
...
This is similar to the problem fixed by commit c5a72a8d1c3 ("[gdb/testsuite]
Fix regexp in gdb.ada/mi_var_access.exp").
The problem in both cases is that we're printing an uninitialized variable,
and consequently we can run into various error messages during printing.
Fix this as in the other commit, by accepting the error message.
Tested on arm-linux.
|
|
Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the
.debug_macro section.
For one malformed macro definition, I get two identical complaints:
...
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
...
Fix this by bailing out after the first one.
Tested on aarch64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
It also tests the gcore script being run without its accessible
terminal.
This test was written by Jan Kratochvil a long time ago. I modernized
the test making it use various procs from lib/gdb.exp, reorganizing it
and added some comments.
Modify the gcore script to make it possible to pass the --data-directory to
it. This prevents a lot of these warnings:
Python Exception <class 'AttributeError'>: module 'gdb' has no attribute
'_handle_missing_debuginfo'
Tested by using make check-all-boards.
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
When building gdb with -g0 and running test-case gdb.gdb/index-file.exp, we
run into:
...
(gdb) save gdb-index index_1^M
Error while writing index for `xgdb': No debugging symbols^M
(gdb) FAIL: gdb.gdb/index-file.exp: create gdb-index file
...
Fix this by instead emitting an unsupported, and bailing out.
Tested on aarch64-linux.
|
|
When running test-case gdb.threads/leader-exit-attach.exp with target board
native-extended-gdbserver I run into:
...
(gdb) KFAIL: $exp: attach (PRMS: gdb/31555)
print $_inferior_thread_count^M
$1 = 0^M
(gdb) KPASS: $exp: get valueof "$_inferior_thread_count" (PRMS server/31554)
...
The PR mentioned in the KPASS, PR31554 was fixed by commit f1fc8dc2dcc
("Fix "attach" failure handling with GDBserver"), and consequently the PR is
closed.
Fix this by removing the corresponding kfail.
Tested on x86_64-linux.
|
|
With test-case gdb.threads/leader-exit-attach.exp and check-read1, I run into:
...
(gdb) attach 18591^M
Attaching to program: leader-exit-attach, process 18591^M
warning: process 18591 is a zombie - the process has already terminatedKFAIL: $exp: attach (PRMS: gdb/31555)
^M
ptrace: Operation not permitted.^M
(gdb) FAIL: $exp: get valueof "$_inferior_thread_count"
...
The problem is that the gdb_test_multiple in the test-case doesn't consume the
prompt in all clauses:
...
gdb_test_multiple "attach $testpid" "attach" {
-re "Attaching to process $testpid failed.*" {
# GNU/Linux gdbserver. Linux ptrace does not let you attach
# to zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "warning: process $testpid is a zombie - the process has already terminated.*" {
# Native GNU/Linux. Linux ptrace does not let you attach to
# zombie threads.
setup_kfail "gdb/31555" *-*-linux*
fail $gdb_test_name
}
-re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" {
pass $gdb_test_name
set attached 1
}
}
...
Fix this by using -wrap in the first two clauses.
While we're at it, also use -wrap in the third clause.
Tested on x86_64-linux.
|
|
After a recent patch review I asked myself why can_spawn_for_attach
exists. This proc currently does some checks, and then calls
can_spawn_for_attach_1 which is an actual caching proc.
The answer is that can_spawn_for_attach exists in order to call
gdb_exit the first time can_spawn_for_attach is called within any test
script.
The reason this is useful is that can_spawn_for_attach_1 calls
gdb_exit. If the user calls can_spawn_for_attach_1 directly then a
problem might exist. Imagine a test written like this:
gdb_start
if { [can_spawn_for_attach_1] } {
... do stuff that assumes GDB is running ...
}
If this test is NOT the first test run, and if an earlier test calls
can_spawn_for_attach_1, then when the above test is run the
can_spawn_for_attach_1 call will return the cached value and gdb_exit
will not be called.
But, if the above test IS the first test run then
can_spawn_for_attach_1 will not return the cached value, but will
instead compute the cached value, a process that ends up calling
gdb_exit. When can_spawn_for_attach_1 returns GDB will have exited
and the test might fail if it is written assuming that GDB is
running.
So can_spawn_for_attach was added which ensures that we _always_ call
gdb_exit the first time can_spawn_for_attach is called within a single
test script, this ensures that in the above case, even if the above is
not the first test script run, gdb_exit will still be called. This
ensures consistent behaviour and avoids some hidden bugs in the
testsuite.
The split between can_spawn_for_attach and can_spawn_for_attach_1 was
introduced in this commit:
commit 147fe7f9fb9a89b217d11d73053f53e8edacf90f
Date: Mon May 6 14:27:09 2024 +0200
[gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach
However, I observe that can_spawn_for_attach is not the only caching
proc that calls gdb_exit. Why does can_spawn_for_attach get special
treatment when surely the same issue exists for any other caching proc
that calls gdb_exit?
I think a better solution is to move the logic from
can_spawn_for_attach into cache.exp and generalise it so that it
applies to all caching procs.
This commit does this by:
1. When the underlying caching proc is executed we track calls to
gdb_exit. If a caching proc calls gdb_exit then this information
is stored in gdb_data_cache (using a ',exit' suffix), and also
written to the cache file if appropriate.
2. When a cached value is returned from gdb_do_cache, if the
underlying proc would have called gdb_exit, and if this is the
first use of the caching proc in this test script, then we call
gdb_exit.
When storing the ',exit' value into the on-disk cache file, the flag
value is stored on a second line. Currently every cached value only
occupies a single line, and a check is added to ensure this remains
true in the future.
To track calls to gdb_exit I eventually settled on using TCL's trace
mechanism. We already make use of this in lib/gdb.exp so I figure
this is OK to use. This should be fine, so long as non of the caching
procs use 'with_override' to replace gdb_exit, or do any other proc
replacement to change gdb_exit, however, I think that is pretty
unlikely.
One issue did come up in testing, a FAIL in gdb.base/break-interp.exp,
prior to this commit can_spawn_for_attach would call gdb_exit before
calling the underlying caching proc. After this call we call gdb_exit
after calling the caching proc.
The underlying caching proc relies on gdb_exit having been called. To
resolve this issue I just added a call to gdb_exit into
can_spawn_for_attach.
With this done can_spawn_for_attach_1 can be renamed to
can_spawn_for_attach, and the existing can_spawn_for_attach can be
deleted.
|
|
In the next commit I want to add more information to
gdb_data_cache (see lib/cache.exp). Specifically I want to track if
the underlying function of a caching proc calls gdb_exit or not.
Currently gdb_data_cache is an associative array, the keys of which
are the name of the caching proc.
In this commit I add a ',value' suffix to the gdb_data_cache keys. In
the next commit I'll add additional entries with a different suffix.
There should be no noticable changes after this commit, this is just a
restructuring.
|
|
On an aarch64-linux system with 32-bit userland running in a chroot, and using
target board unix/mthumb I get:
...
(gdb) hbreak hbreak.c:27^M
Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
(gdb) PASS: gdb.base/hbreak.exp: hbreak
continue^M
Continuing.^M
Unexpected error setting breakpoint: Invalid argument.^M
(gdb) XFAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
...
due to this call in arm_linux_nat_target::low_prepare_to_resume:
...
if (ptrace (PTRACE_SETHBPREGS, pid,
(PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
perror_with_name (_("Unexpected error setting breakpoint"));
...
This problem does not happen if instead we use a 4-byte aligned address.
This may or may not be a kernel bug.
Work around this by first using an inoffensive address bpts[i].address & ~0x7.
Likewise in arm_target::low_prepare_to_resume, which fixes the same fail on
target board native-gdbserver/mthumb.
While we're at it:
- use arm_hwbp_control_is_initialized in
arm_linux_nat_target::low_prepare_to_resume,
- handle the !arm_hwbp_control_is_initialized case explicitly,
- add missing '_()' in arm_target::low_prepare_to_resume,
- make error messages identical between arm_target::low_prepare_to_resume and
arm_linux_nat_target::low_prepare_to_resume,
- factor out sethbpregs_hwbp_address and sethbpregs_hwbp_control to
make the implementation more readable.
Remove the tentative xfail added in d0af16d5a10 ("[gdb/testsuite] Add xfail in
gdb.base/hbreak.exp") by simply reverting the commit.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
It was pointed out in this message:
https://inbox.sourceware.org/gdb-patches/5d7a514b-5dad-446f-a021-444ea88ecf07@redhat.com
That the test gdb.base/build-id-seqno.exp I added recently was FAILing
when using Clang as the compiler.
The problem was that I had failed to add 'build-id' as a compile
option in the call to build_executable within the test script. For
GCC this is fine as build-ids are included by default. For Clang
though this meant the build-id was not included and the test would
fail.
So I added build-id to the compiler options.... and the test still
didn't pass! Now the test fails to compile and I see this error from
the compiler:
gdb compile failed, clang-15: warning: -Wl,--build-id: 'linker' \
input unused [-Wunused-command-line-argument]
It turns out that the build-id compile option causes our gdb.exp to
add the '-Wl,--build-id' option into the compiler flags, which means
its used when building the object file AND during the final link.
However this option is unnecessary when creating the object file and
Clang warns about this, which causes the build to fail.
The solution is to change gdb.exp, instead of adding the build-id
flags like this:
lappend new_options "additional_flags=-Wl,--build-id"
we should instead add them like:
lappend new_options "ldflags=-Wl,--build-id"
Now the flag is only appended during the link phase and Clang is
happy. The gdb.base/build-id-seqno.exp test now passes with Clang.
The same problem (adding to additional_flags instead of ldflags)
exists for the no-build-id compile option, so I've fixed that too.
While investigating this I also spotted two test scripts,
gdb.base/index-cache.exp and gdb.dwarf2/per-bfd-sharing.exp which were
setting ldflag directly rather than using the build-id compile option
so I've updated these two tests to use the compile option which I
think is neater.
I've checked that all these tests still pass with both GCC and Clang.
There should be no changes in what is actually tested after this
commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Consider test.c, compiled with -g:
...
__complex__ float cf = 1 + 2i;
int main (void) { return 0; }
...
The values of cf and its components are:
...
$ gdb -q a.out
Reading symbols from a.out...
(gdb) p cf
$1 = 1 + 2i
(gdb) p $_creal(cf)
$2 = 1
(gdb) p $_cimag(cf)
$3 = 2
...
and their respective types are:
...
(gdb) ptype $1
type = complex float
(gdb) ptype $2
type = float
(gdb) ptype $3
type = float
...
Now let's try that again, using ptype directly:
...
(gdb) ptype cf
type = complex float
(gdb) ptype $_creal(cf)
type = int
(gdb) ptype $_cimag(cf)
type = int
...
The last two types should have been float, not int.
Fix this by extending the internal function handlers creal_internal_fn and
cimag_internal_fn with the noside parameter, such that we get instead:
...
(gdb) ptype $_creal(cf)
type = float
(gdb) ptype $_cimag(cf)
type = float
...
Tested on x86_64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR exp/31816
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31816
|
|
Sometimes, if I'm testing on a loaded machine, the
gdb.gdb/index-file.exp test will timeout during some early steps,
which then cases a TCL error to be thrown later in the test script.
Dejagnu then reports this error once the test run has completed, which
can be pretty noisy, and isn't really very helpful.
The underlying problem is that if GDB takes too long to load the
executable (which is GDB itself in this test) then GDB will still be
busy loading the executable when dejagnu moves on and call
gdb_get_worker_threads. The gdb_get_worker_threads call itself times
out as GDB is _still_ busy loading the executable, and so
gdb_get_worker_threads returns the string "UNKNOWN".
Later we try to perform arithmetic on the worker thread count, which
results in errors when we try to do 'UNKNOWN / 2'.
I propose that after calling gdb_get_worker_threads, we check if the
result was UNKNOWN. If it was then we should report an UNRESOLVED and
abandon the test, this avoids the later TCL errors.
|
|
On s390x-linux, I ran into:
...
(gdb) ptype crash^M
type = class crash {^M
^M
public:^M
crash(int (class {...}::*)(class {...} * const @mode32));^M
}^M
(gdb) FAIL: gdb.dwarf2/dw2-anon-mptr.exp: ptype crash
...
The problem is that the test-case doesn't expect the address class annotation
@mode32.
The test-case uses a .S file, with the address size hard-coded to 4 bytes, and
that's something that is annotated with @mode32 on s390x (which uses 8 byte
addresses).
Fix this by allowing the annotation in the regexp.
Likewise in two other test-cases.
Tested on s390-linux and x86_64-linux.
|
|
With test-case gdb.cp/m-static.exp on arm-linux, I get:
...
(gdb) ptype test5.single_constructor^M
type = class single_constructor {^M
^M
public:^M
single_constructor(void);^M
~single_constructor(void);^M
} *(single_constructor * const)^M
(gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype constructor
...
The test-case expects:
- no empty line before "public:", and
- no "~single_constructor(void)", but "~single_constructor()"
The latter is due to commit 137c886e9a6 ("[gdb/c++] Print destructor the same
for gcc and clang").
The failing test is in a part only enabled for is_aarch32_target == 1, so it
looks like it was left behind.
I'm assuming the same happened for the other difference.
Fix this by updating the regexps to match the observed output.
Tested on arm-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
The DAP spec recently changed to add a new scope for the return value
from a "stepOut" request. This new scope uses the "returnValue"
presentation hint. See:
https://github.com/microsoft/debug-adapter-protocol/issues/458
This patch implements this for gdb.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31945
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
On an aarch64-linux system with 32-bit userland running in a chroot, and using
target board unix/mthumb I get:
...
(gdb) hbreak hbreak.c:27^M
Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M
(gdb) PASS: gdb.base/hbreak.exp: hbreak
continue^M
Continuing.^M
Unexpected error setting breakpoint: Invalid argument.^M
(gdb) FAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak
...
due to this call in arm_linux_nat_target::low_prepare_to_resume:
...
if (ptrace (PTRACE_SETHBPREGS, pid,
(PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0)
perror_with_name (_("Unexpected error setting breakpoint"));
...
This problem does not happen if instead we use a 4-byte aligned address.
I'm not sure if this is simply unsupported or if there's a kernel bug of some
sort, but I don't see what gdb can do about this.
Tentatively mark this as xfail.
Tested on aarch64-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
|
|
On arm-linux, I run into:
...
PASS: gdb.ada/mi_task_arg.exp: mi runto task_switch.break_me
Expecting: ^(-stack-list-arguments 1[^M
]+)?(\^done,stack-args=\[frame={level="0",args=\[\]},frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}(,{name="<_taskL>",value="[0-9]+"})?\]},frame={level="2",args=\[({name="self_id",value="(0x[0-9A-Fa-f]+|<optimized out>)"})?\]},.*[^M
]+[(]gdb[)] ^M
[ ]*)
-stack-list-arguments 1^M
^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[{name="<_task>",value="0x40bc48"}]},frame={level="2",args=[]}]^M
(gdb) ^M
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...
The problem is that the test-case expects a level 3 frame, but there is none.
This can be reproduced using cli bt:
...
$ gdb -q -batch outputs/gdb.ada/mi_task_arg/task_switch \
-ex "b task_switch.break_me" \
-ex run \
-ex bt
Breakpoint 1 at 0x34b4: file task_switch.adb, line 57.
Thread 3 "my_caller" hit Breakpoint 1, task_switch.break_me () \
at task_switch.adb:57
57 null;
#0 task_switch.break_me () at task_switch.adb:57
#1 0x00403424 in task_switch.caller (<_task>=0x40bc48) at task_switch.adb:51
#2 0xf7f95a08 in ?? () from /lib/arm-linux-gnueabihf/libgnarl-12.so
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
...
The purpose of the test-case is printing the frame at level 1, so I don't
think we should bother about the presence of the frame at level 3.
Fix this by allowing the backtrace to stop at level 2.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Fix 'text' to 'test' in a test comment.
|
|
The commit:
commit 22836ca88591ac7efacf06d5b6db191763fd8aba
Date: Tue May 21 09:57:49 2024 +0100
gdb: check for multiple matching build-id files
Was missing a 'require allow_gdbserver_tests' in a gdbserver test.
Add it now.
|
|
When running test-case gdb.dap/rust-slices.exp on aarch64-linux
(debian 12/bookworm), I run into:
...
{"request_seq": 6, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 3, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 261, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}]}, "success": true, "seq": 20}PASS: gdb.dap/rust-slices.exp: get scopes success
FAIL: gdb.dap/rust-slices.exp: three scopes
PASS: gdb.dap/rust-slices.exp: scope is locals
PASS: gdb.dap/rust-slices.exp: locals presentation hint
PASS: gdb.dap/rust-slices.exp: three vars in scope
...
The test-case expects three scopes due to a rust compiler issue:
...
# There are three scopes because an artificial symbol ends up in the
# DWARF. See https://github.com/rust-lang/rust/issues/125126.
gdb_assert {[llength $scopes] == 3} "three scopes"
...
but it seems that the version used here (rustc 1.63.0, llvm 14.0.6) doesn't
have this issue.
Fix this by allowing two or three scopes, and changing the test name to
"two scopes".
Tested on aarch64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR testsuite/31983
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31983
|
|
I noticed that in the 'info breakpoints' output, GDB sometimes prints
the inferior list for pending breakpoints, this doesn't seem right to
me. A pending breakpoint has no locations (at least, as far as we
display things in the 'info breakpoints' output), so including an
inferior list seems odd.
Here's what I see right now:
(gdb) info breakpoint 5
Num Type Disp Enb Address What
5 breakpoint keep y <PENDING> foo inf 1
(gdb)
It's the 'inf 1' at the end of the line that I'm objecting too.
To trigger this behaviour we need to be in a multi-inferior debug
session. The breakpoint must have been non-pending at some point in
the past, and so have a location assigned to it.
The breakpoint becomes pending again as a result of a shared library
being unloaded. When this happens the location itself is marked
pending (via bp_location::shlib_disabled).
In print_one_breakpoint_location, in order to print the inferior list
we check that the breakpoint has a location, and that we have multiple
inferiors, but we don't check if the location itself is pending.
This commit adds that check, which means the output is now:
(gdb) info breakpoint 5
Num Type Disp Enb Address What
5 breakpoint keep y <PENDING> foo
(gdb)
Which I think makes more sense -- indeed, the format without the
inferior list is what we display for a pending breakpoint that has
never had any locations assigned, so I think this change in behaviour
makes GDB more consistent.
|
|
When debugging gdb itself and trying to print a intrusive_list that has
more than one element, I get:
File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 365, in _children_generator
node_ptr = self._as_node_ptr(elem_ptr)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 345, in _as_node_ptr
assert elem_ptr.type.code == gdb.TYPE_CODE_PTR
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
This is because node_ptr is a typedef
(intrusive_list_base_iterator::pointer). Add a call to strip_typedefs
to get to the real type.
Enhance gdb.gdb/python-helper.exp with a test that would have caught
this bug.
Change-Id: I3eaca8de5ed06d05756ed979332b6a431e15b700
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Within the debug-file-directory GDB looks for the existence of a
.build-id directory.
Within the .build-id directory GDB looks for files with the form:
.build-id/ff/4b4142d62b399499844924d53e33d4028380db.debug
which contain the debug information for the objfile with the build-id
ff4b4142d62b399499844924d53e33d4028380db.
There appear to be two strategies for populating the .build-id
directory. Ubuntu takes the approach of placing the actual debug
information in this directory, so
4b4142d62b399499844924d53e33d4028380db.debug is an actual file
containing the debug information.
Fedora, RHEL, and SUSE take a slightly different approach, placing the
debug information elsewhere, and then creating symlinks in the
.build-id directory back to the original debug information file. The
actual debug information is arranged in a mirror of the filesystem
within the debug directory, as an example, if the debug-file-directory
is /usr/lib/debug, then the debug information for /bin/foo can be
found in /usr/lib/debug/bin/foo.debug.
Where this gets interesting is that in some cases a package will
install a single binary with multiple names, in this case a single
binary will be install with either hard-links, or symlinks providing
the alternative names.
The debug information for these multiple binaries will then be placed
into the /usr/lib/debug/ tree, and again, links are created so a
single file can provide debug information for each of the names that
binary presents as. An example file system might look like this (the
[link] could be symlinks, but are more likely hard-links):
/bin/
foo
bar -> foo [ HARD LINK ]
baz -> foo [ HARD LINK ]
/usr/
lib/
debug/
bin/
foo.debug
bar.debug -> foo.debug [ HARD LINK ]
baz.debug -> foo.debug [ HARD LINK ]
In the .build-id tree though we have a problem. Do we have a single
entry that links to one of the .debug files? This would work; a user
debugging any of the binaries will find the debug information based on
the build-id, and will get the correct information, after all the
.debug files are identical (same file linked together). But there is
one problem with this approach.
Sometimes, for *reasons* it's possible that one or more the linked
binaries might get removed, along with its associated debug
information. I'm honestly not 100% certain under what circumstances
this can happen, but what I observe is that sometime a single name for
a binary, and its corresponding .debug entry, can be missing. If this
happens to be the entry that the .build-id link is pointing at, then
we have a problem. The user can no longer find the debug information
based on the .build-id link.
The solution that Fedora, RHEL, & SUSE have adopted is to add multiple
entries in the .build-id tree, with each entry pointing to a different
name within the debug/ tree, a sequence number is added to the
build-id to distinguish the multiple entries. Thus, we might end up
with a layout like this:
/bin/
foo
bar -> foo [ HARD LINK ]
baz -> foo [ HARD LINK ]
/usr/
lib/
debug/
bin/
foo.debug
bar.debug -> foo.debug [ HARD LINK ]
baz.debug -> foo.debug [ HARD LINK ]
.build-id/
a3/
4b4142d62b399499844924d53e33d4028380db.debug -> ../../debug/bin/foo.debug [ SYMLINK ]
4b4142d62b399499844924d53e33d4028380db.1.debug -> ../../debug/bin/bar.debug [ SYMLINK ]
4b4142d62b399499844924d53e33d4028380db.2.debug -> ../../debug/bin/baz.debug [ SYMLINK ]
With current master GDB, debug information will only ever be looked up
via the 4b4142d62b399499844924d53e33d4028380db.debug link. But if
'foo' and its corresponding 'foo.debug' are ever removed, then master
GDB will fail to find the debug information.
Ubuntu seems to have a much better approach for debug information
handling; they place the debug information directly into the .build-id
tree, so there only ever needs to be a single entry for any one
build-id. I wonder if/how they handle the case where multiple names
might share a single .debug file, if one of those names is then
uninstalled, how do they know the .debug file should be retained or
not ... but I assume that problem either doesn't exist or has been
solved.
Anyway, for a while Fedora has carried a patch that handles the
build-id sequence number logic. What's presented here is inspired by
the Fedora patch, but has some changes to fix some issues.
I'm aware that this is a patch that applies to only some (probably a
minority) of distros. However, the logic is contained to only a
single function in build-id.c, and isn't too complex, so I'm hoping
that there wont be too many objections.
For distros that don't have build-id sequence numbers there should be
no impact. The sequence number approach still leaves the first file
without a sequence number, and this is the first file that GDB (after
this patch) checks for. The new logic only kicks in if the
non-sequence numbered first file exists, but is a symlink to a non
existent file; in this case GDB checks for the sequence numbered files
instead.
Tests are included.
There is a small fix needed for gdb.base/sysroot-debug-lookup.exp,
after this commit GDB now treats a target: sysroot where the target
file system is local to GDB the same as if the sysroot had no target:
prefix. The consequence of this is that GDB now resolves a symlink
back to the real filename in the sysroot-debug-lookup.exp test where
it didn't previously. As this behaviour is inline with the case where
there is no target: prefix I think this is fine.
|
