aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2024-08-02gdb: remove uses of VLASimon Marchi13-85/+86
Remove uses of VLAs, replace with gdb::byte_vector. There might be more in files that I can't compile, but it's difficult to tell without actually compiling on all platforms. Many thanks to the Linaro pre-commit CI for helping find some problems with an earlier iteration of this patch. Change-Id: I3e5e34fcac51f3e6b732bb801c77944e010b162e Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-08-02gdb,testsuite: fix gdb.base/list-dot-nodebug and make it more robustGuinevere Larsen1-11/+26
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>
2024-08-02gdb: remove inline_frame::skipped_framesSimon Marchi1-29/+22
While reviewing [1], it occurred to me that having both the skipped_frames counter and the skipped_syms vector is redundant. When stepping into an inline frame, we can just pop the last element. [1] https://inbox.sourceware.org/gdb-patches/96cfee31-6a50-4a78-a25b-67e5d061c2a3@simark.ca/T/#m7e0e4b5b6cfc91be3d8ab6d5025a97c2e647103a Change-Id: I8c10e7fcd05e41c2c838431d06c9e793d18a2198 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-08-02gdb/testsuite: fix gdb.python/py-framefilter-invalidarg.exp with clangGuinevere Larsen1-1/+1
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>
2024-08-02gdb/testsuite: extend XFAIL to gdb.fortran/entry-point.exp to clang tooGuinevere Larsen1-2/+2
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>
2024-08-02gdb/testsuite: add build-id compile flag to tests that expect itGuinevere Larsen4-4/+6
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>
2024-08-01gdb: LoongArch: Add show-debug-regs maintenance commandHui Li1-0/+16
This patch register the command "maint set show-debug-regs on/off" and make it settable by the user. If show-debug-regs is enabled, the debug register values are shown when GDB inserts or removes a hardware breakpoint or watchpoint. This is helpful for the use and development of hardware watchpoints. With this patch, the effect of this maintenance command as follows: lihui@bogon:~$ cat test.c int a = 0; int main() { a = 1; return 0; } lihui@bogon:~$ gcc -g test.c -o test lihui@bogon:~$ gdb test ... (gdb) watch a Hardware watchpoint 1: a (gdb) maint set show-debug-regs on (gdb) r Starting program: /home/lihui/test ... ... prepare_to_resume thread 41525 ... insert_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint): BREAKPOINTs: BP0: addr=0x0, ctrl=0x00000000, ref.count=0 BP1: addr=0x0, ctrl=0x00000000, ref.count=0 BP2: addr=0x0, ctrl=0x00000000, ref.count=0 BP3: addr=0x0, ctrl=0x00000000, ref.count=0 BP4: addr=0x0, ctrl=0x00000000, ref.count=0 BP5: addr=0x0, ctrl=0x00000000, ref.count=0 BP6: addr=0x0, ctrl=0x00000000, ref.count=0 BP7: addr=0x0, ctrl=0x00000000, ref.count=0 WATCHPOINTs: WP0: addr=0x0, ctrl=0x00000000, ref.count=0 WP1: addr=0x0, ctrl=0x00000000, ref.count=0 WP2: addr=0x0, ctrl=0x00000000, ref.count=0 WP3: addr=0x0, ctrl=0x00000000, ref.count=0 WP4: addr=0x0, ctrl=0x00000000, ref.count=0 WP5: addr=0x0, ctrl=0x00000000, ref.count=0 WP6: addr=0x0, ctrl=0x00000000, ref.count=0 WP7: addr=0x12000803c, ctrl=0x00000610, ref.count=1 ... remove_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint): BREAKPOINTs: BP0: addr=0x0, ctrl=0x00000000, ref.count=0 BP1: addr=0x0, ctrl=0x00000000, ref.count=0 BP2: addr=0x0, ctrl=0x00000000, ref.count=0 BP3: addr=0x0, ctrl=0x00000000, ref.count=0 BP4: addr=0x0, ctrl=0x00000000, ref.count=0 BP5: addr=0x0, ctrl=0x00000000, ref.count=0 BP6: addr=0x0, ctrl=0x00000000, ref.count=0 BP7: addr=0x0, ctrl=0x00000000, ref.count=0 WATCHPOINTs: WP0: addr=0x0, ctrl=0x00000000, ref.count=0 WP1: addr=0x0, ctrl=0x00000000, ref.count=0 WP2: addr=0x0, ctrl=0x00000000, ref.count=0 WP3: addr=0x0, ctrl=0x00000000, ref.count=0 WP4: addr=0x0, ctrl=0x00000000, ref.count=0 WP5: addr=0x0, ctrl=0x00000000, ref.count=0 WP6: addr=0x0, ctrl=0x00000000, ref.count=0 WP7: addr=0x0, ctrl=0x00000000, ref.count=0 Hardware watchpoint 1: a Old value = 0 New value = 1 main () at test.c:5 5 return 0; (gdb) Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2024-08-01gdb: AArch64: Support MTE on baremetalGustavo Romero11-251/+308
This commit moves aarch64_linux_memtag_matches_p, aarch64_linux_set_memtags, aarch64_linux_get_memtag, and aarch64_linux_memtag_to_string hooks (plus the aarch64_mte_get_atag function used by them), along with the setting of the memtag granule size, from aarch64-linux-tdep.c to aarch64-tdep.c, making MTE available on baremetal targets. Since the aarch64-linux-tdep.c layer inherits these hooks from aarch64-tdep.c, there is no effective change for aarch64-linux targets. Helpers used both by aarch64-tdep.c and by aarch64-linux-tdep.c were moved from arch/aarch64-mte-linux.{c,h} to new arch/aarch64-mte.{c,h} files. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-08-01[gdb/testsuite] Fix gdb.python/py-format-string.exp with python 3.13Tom de Vries1-1/+7
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
2024-07-31[gdb/testsuite] Fix trailing-text-in-parentheses duplicatesTom de Vries77-627/+618
Fix all trailing-text-in-parentheses duplicates exposed by previous patch. Tested on x86_64-linux and aarch64-linux.
2024-07-31[gdb/testsuite] Detect trailing-text-in-parentheses duplicatesTom de Vries2-5/+39
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
2024-07-31[gdb/testsuite] Add gdb.python/py-disasm-{exec,obj}.expTom de Vries4-16/+90
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.
2024-07-31[gdb/exp] Fix gdb.fortran/intrinsics.exp fail on armTom de Vries4-18/+70
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
2024-07-30[gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp some moreTom de Vries1-1/+2
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.
2024-07-30gdb: don't call macro_bcache with nullptrSimon Marchi1-6/+9
Since commit b1da98a74656 ("gdb: remove use of alloca in new_macro_definition"), if cached_argv is empty, we call macro_bcache with a nullptr data. This ends up caught by UBSan deep down in the bcache code: $ ./gdb -nx -q --data-directory=data-directory /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp -readnow Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp... Expanding full symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp... /home/smarchi/src/binutils-gdb/gdb/bcache.c:195:12: runtime error: null pointer passed as argument 2, which is declared to never be null The backtrace: #1 0x00007ffff619a05d in __ubsan::__ubsan_handle_nonnull_arg_abort (Data=<optimized out>) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:750 #2 0x000055556337fba2 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.c:195 #3 0x0000555564b49222 in gdb::bcache::insert<char const*, void> (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.h:158 #4 0x0000555564b481fa in macro_bcache<char const*> (t=0x62100007ae70, addr=0x0, len=0) at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:117 #5 0x0000555564b42b4a in new_macro_definition (t=0x62100007ae70, kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:573 #6 0x0000555564b44674 in macro_define_internal (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:777 #7 0x0000555564b44ae2 in macro_define_function (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:816 #8 0x0000555563f62fc8 in parse_macro_definition (file=0x6210000ab9e0, line=469, body=0x62a00003af2a "__va_arg_pack() __builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:203 This can be reproduced by running gdb.base/macscp.exp. Avoid calling macro_bcache if the macro doesn't have any arguments. Change-Id: I33b5a7c3b3a93d5adba98983fcaae9c8522c383d
2024-07-30[gdb/symtab] Emit malformed macro definition complaint onceTom de Vries2-1/+202
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>
2024-07-30gdb: remove use of alloca in new_macro_definitionSimon Marchi1-5/+4
Replace alloca with std::vector. Change-Id: Ie8756da09126f6808e5b52c43388ad9324e8ad2c Approved-By: Tom de Vries <tdevries@suse.de>
2024-07-30gdb: use std::string vector for macro definitionSimon Marchi4-144/+81
Use std::vector<std::string> when defining macros, to avoid the manual memory management. With the use of std::vector, the separate `int argc` parameter is no longer needed, we can use the size of the vector instead. However, for some functions, this parameter had a dual function. For object-like macros, it was interpreted as a `macro_special_kind` enum. For these functions, remove `argc`, but add a new `special_kind` parameter. Change-Id: Ice76a6863dfe598335e3b8d5d077513e50975cc5 Approved-By: Tom de Vries <tdevries@suse.de>
2024-07-30gdb/doc: move @anchor off @item lineAndrew Burgess1-1/+2
When building the GDB info manual I see this warning: gdb.texinfo:41447: warning: @anchor should not appear on @item line And indeed line 41447 looks like this: @item @anchor{maint info breakpoints}maint info breakpoints I propose moving the @anchor{...} part to the previous line which silences the warning. Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-07-29Add a test for the gcore scriptAlexandra Hájková5-4/+189
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>
2024-07-29[gdb/testsuite] Fix gdb.gdb/index-file.exp with -g0Tom de Vries1-2/+13
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.
2024-07-29[gdb/testsuite] Remove PR31554 kfail in gdb.threads/leader-exit-attach.expTom de Vries1-8/+0
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.
2024-07-29[gdb/testsuite] Fix gdb.threads/leader-exit-attach.exp with check-read1Tom de Vries1-3/+3
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.
2024-07-28gdb/testsuite: track if a caching proc calls gdb_exit or notAndrew Burgess2-74/+135
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.
2024-07-28gdb/testsuite: restructure gdb_data_cache (lib/cache.exp)Andrew Burgess1-9/+9
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.
2024-07-27[gdb/tdep] Fix arm thumb2 hw breakpointTom de Vries2-44/+94
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>
2024-07-26gdb/testsuite: fix build-id compile option when used with clangAndrew Burgess4-5/+6
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>
2024-07-25gdb/amdgpu: remove unused includesSimon Marchi1-2/+0
Remove two includes reported as unused by clangd. Change-Id: Idfe27a6c21186de5bd5f8e8f7fdc0fd8ab4d451e
2024-07-24Remove redundant macro definitions from remote.cTom Tromey1-11/+0
I happened to notice that a few macros are defined twice in remote.c. This patch removes one copy. Tested by rebuilding. Reviewed-By: Tom de Vries <tdevries@suse.de>
2024-07-24[gdb/exp] Fix ptype $_creal/$_cimagTom de Vries2-8/+25
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
2024-07-24[gdb/exp] Allow internal function to indicate return typeTom de Vries5-31/+100
Currently an internal function handler has this prototype: ... struct value *handler (struct gdbarch *gdbarch, const struct language_defn *language, void *cookie, int argc, struct value **argv); ... Also allow an internal function with a handler with an additional "enum noside noside" parameter: ... struct value *handler (struct gdbarch *gdbarch, const struct language_defn *language, void *cookie, int argc, struct value **argv, enum noside noside); ... In case such a handler is called with noside == EVAL_AVOID_SIDE_EFFECTS, it's expected to return some value with the correct return type. At least, provided it can do so without side effects, otherwise it should throw an error. No functional changes. Tested on x86_64-linux and aarch64-linux. Reviewed-By: Keith Seitz <keiths@redhat.com>
2024-07-24gdb/testsuite: ensure gdb_get_worker_threads succeedsAndrew Burgess1-0/+5
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.
2024-07-24[gdb/testsuite] Handle address class annotation for s390x in some test-casesTom de Vries3-7/+42
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.
2024-07-24[gdb/testsuite] Fix gdb.cp/m-static.exp on armTom de Vries2-4/+19
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>
2024-07-23Add returnValue scope to DAPTom Tromey3-16/+25
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>
2024-07-23Refine the 'define' documentationTom Tromey1-6/+16
A while ago, an AdaCore user reported some difficulties with the 'define' command. While some of these difficulties are intrinsic, or at least difficult to change, it seemed sensible to document a couple of the typical problems -- and to make the text describing argument substitution a bit more prominent. Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-07-23gdb/solib-frv: move lm_info object to solibSimon Marchi1-0/+2
I noticed that the lm_info_frv objects created in frv_current_sos are never moved to the solib object. This bug was introduced in 8971d2788e ("gdb: link so_list using intrusive_list"), which mistakenly removed the line sop->lm_info = std::move (li); ... probably due so a bad merge conflict resolution. Re-add this line. If merged in master, I would cherry-pick this to gdb-15-branch. Change-Id: I609a1a5ad39e93f70a95ea5ebe3f8ff4ab6a8db2 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32005 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-07-23[gdb/testsuite] Add xfail in gdb.base/hbreak.expTom de Vries1-6/+34
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>
2024-07-23[gdb/testsuite] Fix gdb.ada/mi_task_arg.exp on arm-linuxTom de Vries1-3/+4
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>
2024-07-22gdb/unittests/intrusive-list: remove unnecessary local objectsSimon Marchi1-1/+0
These objects are not used. Change-Id: I90127f7b2d1543718c841b54173521d9ab3f652f
2024-07-22gdb/solib: pass program space to solib_usedSimon Marchi1-6/+7
Make the current program space reference bubble up one level. Change-Id: I6113c9ef57cb31ca8ea129ab58e7c318c09b5123
2024-07-22gdb/remote: remove an out of date commentAndrew Burgess1-3/+0
A comment above an `if` check was accidentally left in place after this commit: commit ddb3f3d89cf62df6be3cb9e110504def19625160 Date: Tue Mar 19 12:34:34 2024 +0100 Add "error_message+" feature to qSupported The comment relates to how 'E.msg' style remote replies are not supported by every packet, but after the above commit they are supported in all cases (that call packet_check_result), and the comment should have been removed.
2024-07-22gdb/testsuite: fix minor typo in a commentAndrew Burgess1-1/+1
Fix 'text' to 'test' in a test comment.
2024-07-21gdb/testsuite: Add missing 'require allow_gdbserver_tests'Andrew Burgess1-0/+2
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.
2024-07-21[gdb/testsuite] Fix scopes check in gdb.dap/rust-slices.expTom de Vries1-3/+3
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
2024-07-20gdb: remove tracepoint_probe_create_sals_from_location_specAndrew Burgess1-16/+3
The tracepoint_probe_create_sals_from_location_spec function just forwards all its arguments to bkpt_probe_create_sals_from_location_spec, and is only used in one place. Lets delete tracepoint_probe_create_sals_from_location_spec and replace it with bkpt_probe_create_sals_from_location_spec. There should be no user visible changes after this commit.
2024-07-20gdb: remove breakpoint_re_set_oneAndrew Burgess1-18/+8
During a later patch I wanted to reset a single breakpoint, so I called breakpoint_re_set_one. However, this is not the right thing to do. If we look at breakpoint_re_set then we see that there's a whole bunch of state that needs to be preserved prior to calling breakpoint_re_set_one, and after calling breakpoint_re_set_one we still need to call update_global_location_list. I could just update the comment on breakpoint_re_set_one to make it clearer how the function should be used -- or more likely to warn that the function should only be used as a helper from breakpoint_re_set. However, breakpoint_re_set_one is only 3 lines long. So I figure it might actually be easier to just fold breakpoint_re_set_one into breakpoint_re_set, then there's no risk of accidentally calling breakpoint_re_set_one when we shouldn't. There should be no user visible changes after this commit.
2024-07-20gdb: don't display inferior list for pending breakpointsAndrew Burgess4-1/+215
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.
2024-07-19gdb-gdb.py: strip typedefs in intrusive_list printer assertionSimon Marchi2-1/+16
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>
2024-07-18gdb: check for multiple matching build-id filesAndrew Burgess6-46/+516
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.
generated by cgit v1.1 at 2025-09-19 22:45:00 +0000