aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-06-09gdb/solib-svr4: remove svr4_have_link_map_offsetsSimon Marchi1-18/+0
While C++ifying the solib code, I concluded that all arches that use SVR4 libraries do provide link map offsets, so I think this function is unnecessary now. Change-Id: Ifaae2560d92f658df3724def6219e2f89054e4b7 Approved-By: Tom Tromey <tom@tromey.com>
2025-06-09Adjust gdb.cp/cpexprs.exp for CygwinPedro Alves1-10/+26
Running gdb.cp/cpexprs.exp on x86-64 GNU/Linux, I see: break base::~base Breakpoint 117 at 0x555555555d90: file .../src/gdb/testsuite/gdb.cp/cpexprs.cc, line 135. (gdb) continue Continuing. Breakpoint 117, base::~base (this=0x7fffffffd0f8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135 135 ~base (void) { } // base::~base (gdb) PASS: gdb.cp/cpexprs.exp: continue to base::~base Here, the breakpoint only got one location because both the in-charge and the not-in-charge dtors are identical and got the same address: $ nm -A ./testsuite/outputs/gdb.cp/cpexprs/cpexprs| c++filt |grep "~base" ./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base() ./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base() While on Cygwin, we get two locations for the same breakpoint, which the testcase isn't expecting: break base::~base Breakpoint 117 at 0x100402678: base::~base. (2 locations) (gdb) continue Continuing. Thread 1 "cpexprs" hit Breakpoint 117.1, base::~base (this=0x7ffffcaf8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135 135 ~base (void) { } // base::~base (gdb) FAIL: gdb.cp/cpexprs.exp: continue to base::~base We got two locations because the in-charge and the not-in-charge dtors have different addresses: $ nm -A outputs/gdb.cp/cpexprs/cpexprs.exe | c++filt | grep "~base" outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402680 T base::~base() outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402690 T base::~base() On Cygwin, we also see the typical failure due to not expecting the inferior to be multi-threaded: (gdb) continue Continuing. [New Thread 628.0xe08] Thread 1 "cpexprs" hit Breakpoint 200, test_function (argc=1, argv=0x7ffffcc20) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:336 336 derived d; (gdb) FAIL: gdb.cp/cpexprs.exp: continue to test_function for policyd3::~policyd Both issues are fixed by this patch, and now the testcase passes cleanly on Cygwin, for me. Reviewed-By: Keith Seitz <keiths@redhat.com> Change-Id: If7eb95d595f083f36dfebf9045c0fc40ef5c5df1
2025-06-09gdb.threads/thread-execl, don't re-exec foreverPedro Alves1-2/+8
I noticed on Cygwin, gdb.thread/thread-execl.exp would hang, (not that surprising since we can't follow-exec on Cygwin). Looking at the process list running on the machine, we end up with a thread-execl.exe process constantly respawning another process [1]. We see the same constant-reexec if we launch gdb.thread/thread-execl manually on the shell: $ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl # * doesn't exit, constantly re-execing * ^C Prevent this leftover constantly-re-execing scenario by making the testcase program only exec once. We now get: $ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl $ # exits immediately after one exec. On Cygwin, the testcase now fails reasonably quickly, and doesn't leave stale processes behind. Still passes cleanly on x86-64 GNU/Linux. [1] Cygwin's exec emulation spawns a new Windows process for the new image. Approved-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I0de1136cf2ef7e89465189bc43489a2139a80efb
2025-06-09Support core dumping testcases with Cygwin's dumperPedro Alves1-1/+6
Cygwin supports dumping ELF cores via a dumper.exe utility, see https://www.cygwin.com/cygwin-ug-net/dumper.html. When I run a testcase that has the "kernel" generate a corefile, like gdb.base/corefile.exp, Cygwin invokes dumper.exe correctly and generates an ELF core file, however, the testsuite doesn't find the generated core: Running /home/alves/gdb/src/gdb/testsuite/gdb.base/corefile.exp ... WARNING: can't generate a core file - core tests suppressed - check ulimit -c The file is correctly put under $coredir, e.g., like so: outputs/gdb.base/corefile/coredir.8926/corefile.exe.core The problem is in this line in core_find: foreach i "${coredir}/core ${coredir}/core.coremaker.c ${binfile}.core" { Note that that isn't looking for "${binfile}.core" inside ${coredir}... That is fixed in this patch. However, that still isn't sufficient for Cygwin + dumper, as in that case the core is going to be called foo.exe.core, not foo.core. Fix that by looking for foo.exe.core in the core dir as well. With this, gdb.base/corefile.exp and other tests that use core_find now run. They don't pass cleanly, but at least now they're exercised. Approved-By: Tom Tromey <tom@tromey.com> Change-Id: Ic807dd2d7f22c5df291360a18c1d4fbbbb9b993e
2025-06-09Adjust gdb.base/sigall.exp for CygwinPedro Alves1-4/+5
The gdb.base/sigall.exp testcase has many FAILs on Cygwin currently. From: Thread 1 "sigall" received signal SIGPWR, Power fail/restart. 0x00007ffeac9ed134 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll (gdb) FAIL: gdb.base/sigall.exp: get signal LOST we see two issues. The test is expecting "Program received ..." which only appears if the inferior is single-threaded. All Cygwin inferiors are multi-threaded, because both Windows and the Cygwin runtime spawn a few helper threads. And then, SIGLOST is the same as SIGPWR on Cygwin. The testcase already knows to treat them the same on SPARC64 GNU/Linux. We just need to extend the relevant code to treat Cygwin the same. With this, the test passes cleanly on Cygwin. Approved-By: Tom Tromey <tom@tromey.com> Change-Id: Ie3553d043f4aeafafc011347b6cb61ed58501667
2025-06-09Adjust gdb.arch/amd64-watchpoint-downgrade.exp for CygwinPedro Alves1-1/+1
The gdb.arch/amd64-watchpoint-downgrade.exp testcase is assuming the output of debugging a single-thread program, like so, on e.g., GNU/Linux: starti Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade warning: watchpoint 1 downgraded to software watchpoint Program stopped. 0x00007ffff7fe32b0 in _start () from /lib64/ld-linux-x86-64.so.2 However, on Cygwin, where all inferiors are multi-threaded (because both Windows and the Cygwin runtime spawn a few helper threads), we get: starti Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade [New Thread 4652.0x17e4] warning: watchpoint 1 downgraded to software watchpoint Thread 1 stopped. 0x00007ffbfc1c0911 in ntdll!LdrInitShimEngineDynamic () from C:/Windows/SYSTEM32/ntdll.dll This commit adjusts the testcase to work with either output. (Note GDB may print a thread name after the thread number.) Approved-by: Kevin Buettner <kevinb@redhat.com> Change-Id: I3aedfec04924ea3fb3bb87ba3251e2b720f8d59c
2025-06-09Adjust gdb.base/bp-permanent.exp for CygwinPedro Alves1-2/+2
On Cygwin, all inferiors are multi-threaded, because both Windows and the Cygwin runtime spawn a few helper threads. Adjust the gdb.base/bp-permanent.exp testcase to work with either single- or multi-threaded inferiors. Approved-by: Kevin Buettner <kevinb@redhat.com> Change-Id: I28935b34fc9f739c2a5490e83aa4995d29927be2
2025-06-09Adjust gdb.base/bp-cond-failure.exp for CygwinPedro Alves1-2/+2
Currently on Cygwin, I get: Running /home/alves/gdb/src/gdb/testsuite/gdb.base/bp-cond-failure.exp ... FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: single-loc: continue FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: multi-loc: continue FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: single-loc: continue FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: multi-loc: continue FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: single-loc: continue FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: multi-loc: continue FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: single-loc: continue On GNU/Linux, we see: Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21 21 return 0; /* Multi-location breakpoint here. */ (gdb) PASS: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue While on Cygwin, we see: Thread 1 "bp-cond-failure" hit Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21 21 return 0; /* Multi-location breakpoint here. */ (gdb) FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue The difference is the "Thread 1" part in the beginning of the quoted output. It appears on Cygwin, but not on Linux. That's because on Cygwin, all inferiors are multi-threaded, because both Windows and the Cygwin runtime spawn a few helper threads. Fix this by adjusting the gdb.base/bp-cond-failure.exp testcase to work with either single- or multi-threaded inferiors. The testcase passes cleanly for me after this. Approved-by: Kevin Buettner <kevinb@redhat.com> Change-Id: I5ff11d06ac1748d044cef025f1e78b8f84ad3349
2025-06-09MAINTAINERS: Add myself as an AArch64 maintainerAlice Carlotti1-0/+1
2025-06-09aarch64: Increase the number of feature words to 3Richard Earnshaw1-1/+2
Now that most of the effort of updating the number of feature words is handled by macros, add an additional one, taking the number of supported features to 192.
2025-06-09aarch64: use macro trickery to automate feature array size replicationRichard Earnshaw1-36/+87
There are quite a few macros that need to be changed when we need to increase the number of words in the features data structure. With some macro trickery we can automate most of this so that a single macro needs to be updated. With C2X we could probably do even better by using recursion, but this is still a much better situation than we had previously. A static assertion is used to ensure that there is always enough space in the flags macro for the number of feature bits we need to support.
2025-06-09aarch64: Fix typos in opcode headersYury Khrustalev2-6/+6
2025-06-09change some listing.c variables to unsigned.Alan Modra3-16/+16
The values are unsigned, and changing the types allows some casts to be removed.
2025-06-09dwarf2dbg.c line_entry.next assertAlan Modra1-7/+15
I was puzzling over how it was correct to cast what is clearly a struct line_entry** pointer to a struct line_entry* pointer for a few moments, and was going to write a comment but then decided we really don't require the "next" pointer to be where it is. Replace the assert with an inline function that does any necessary pointer adjustments. * dwarf2dbg.c (line_entry.next): Delete static assertion. (line_entry_at_tail): New inline function. (dwarf2_gen_line_info_1, dwarf2_finish): Replace casts in set_or_check_view arguments with line_entry_at_tail.
2025-06-09str_hash_find castsAlan Modra53-259/+195
Putting an explicit cast on the void* return from str_hash_find isn't necessary and doesn't add much to code clarity. In other cases, poor choice of function parameter types, eg. "void *value" in tc-aarch64.c checked_hash_insert rather than "const void *value" leads to needing (void *) casts all over the place just to cast away const. Fix that by correcting the parameter type. (And it really is a const, the function and str_hash_insert don't modify the strings.) This patch also removes some unnecessary casts in hash.c
2025-06-09str_hash_find_intAlan Modra8-174/+145
This changes the internal representation of string_tuple.value from a void* to an intptr_t, removing any concerns that code wanting to store an integer value will use values that are trap encodings or suchlike for a pointer. The ISO C standard says any void* can be converted to intptr_t and back again and will compare equal to the original pointer. It does *not* say any intptr_t can be converted to void* and back again to get the original integer.. Two new functions, str_hash_find_int and str_hash_insert_int are provided for handling integer values. str_hash_find_int returns (intptr_t) -1 on failing to find the key string. Most target code need minimal changes to use the new interface, but some simplification is possible since now a zero can be stored and differentiated from the NULL "can't find" return. (Yes, that means (intptr_t) -1 can't be stored.) I've changed the avr_no_sreg_hash dummy value to zero, and the loongarch register numbers don't need to be incremented. loongarch also doesn't need to store an empty key string (if it ever did).
2025-06-09metag build errorAlan Modra1-5/+4
gas/config/tc-metag.c: In function ‘parse_dsp_addr’: gas/config/tc-metag.c:4386:29: error: ‘regs[0]’ may be used uninitialized [-Werror=maybe-uninitialized] 4386 | if (!is_addr_unit (regs[0]->unit) && | ~~~~~~~^~~~~~ It looks like regs_read can be zero with "l" non-NULL, so this gcc complaint is accurate. * config/tc-metag.c (parse_dsp_addr, parse_dget_set): Check regs_read.
2025-06-09Automatic date update in version.inGDB Administrator1-1/+1
2025-06-08Automatic date update in version.inGDB Administrator1-1/+1
2025-06-07[gdb/build] Fix buildbreaker in hardwire_setbaudrateTom de Vries1-1/+1
When building on x86_64-cygwin, I run into: ... In file included from gdbsupport/common-defs.h:203, from gdb/defs.h:26, from <command-line>: gdb/ser-unix.c: In function ‘void hardwire_setbaudrate(serial*, int)’: gdbsupport/gdb_locale.h:28:20: error: expected ‘)’ before ‘gettext’ 28 | # define _(String) gettext (String) | ^~~~~~~ gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’ 43 | internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \ | ^ gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’ 590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes")); | ^~~~~~~~~~~~~~~~~~~~~~ gdb/ser-unix.c:590:31: note: in expansion of macro ‘_’ 590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes")); | ^ gdbsupport/gdb_locale.h:28:28: note: to match this ‘(’ 28 | # define _(String) gettext (String) | ^ gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’ 43 | internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \ | ^ gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’ 590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes")); | ^~~~~~~~~~~~~~~~~~~~~~ ... Fix this by dropping the unneeded _() on the gdb_assert_not_reached argument. PR build/33064 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33064
2025-06-07[gdb/testsuite] Fix gdb.ada/dyn-bit-offset.exp on s390xTom de Vries2-6/+39
On s390x-linux, with test-case gdb.ada/dyn-bit-offset.exp and gcc 7.5.0 I get: ... (gdb) print spr^M $1 = (discr => 3, array_field => (-5, -6, -7), field => -6, another_field => -6)^M (gdb) FAIL: $exp: print spr print spr.field^M $2 = -6^M (gdb) FAIL: $exp: print spr.field ... On x86_64-linux, with the same compiler version I get: ... (gdb) print spr^M $1 = (discr => 3, array_field => (-5, -6, -7), field => -4, another_field => -4)^M (gdb) XFAIL: $exp: print spr print spr.field^M $2 = -4^M (gdb) PASS: $exp: print spr.field ... In both cases, we're hitting the same compiler problem, but it manifests differently on little and big endian. Make sure the values seen for both little and big endian trigger xfails for both tests. Printing spr.field gives the expected value -4 for x86_64, but that's an accident. Change the actual spr.field value to -5, to make sure that we get the same number of xfails on x86_64 and s390x. Finally, make the xfails conditional on the compiler version. Tested using gcc 7.5.0 on both x86_64-linux and s390x-linux. Approved-By: Andrew Burgess <aburgess@redhat.com> PR testsuite/33042 https://sourceware.org/bugzilla/show_bug.cgi?id=33042
2025-06-07AVR: ld/32968 - Assert that .progmem data resides in the lower 64 KiB.Georg-Johann Lay2-10/+15
This patch locates the linker stubs / trampolines *after* all the .progmem sections. This is the natural placement since progmem data has to reside in the lower 64 KiB (it is accessed using LPM), whereas the linker stubs are only required to be located in the lower 128 KiB of program memory. (They must be in the range of EICALL / EIJMP with EIND = 0.) The current location of the linker stubs was motivated by an invalid test case from PR13812 that allocates more than 64 KiB of progmem data. The patch adds an assertion that makes sure that no progmem data is allocated past 0xffff. Data that is accessed using ELPM should be located to .progmemx so that no .progmem addresses are wasted. .progmemx was introduced in 2017 and is used by __memx, __flashx and by the current AVR-LibC. (The compiler uses .jumptables.gcc for its jump dispatch tables since https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223 / GCC v4.9.2). PR ld/32968 ld/ * scripttempl/avr.sc: Move the trampolines section after the .progmem sections. Assert that .progmem is in the lower 64 KiB.
2025-06-07Automatic date update in version.inGDB Administrator1-1/+1
2025-06-06gdb/guile: fix memory leak in gdbscm_parse_command_nameAndrew Burgess1-0/+8
For reference see the previous commit. Fix a memory leak in gdbscm_parse_command_name when a guile exception is thrown. To reveal the memory leak I placed the following content into a file 'leak.scm': (use-modules (gdb)) (register-command! (make-command "break cmd" #:command-class COMMAND_OBSCURE #:invoke (lambda (self arg from-tty) (display "Hello World")))) Then in GDB: (gdb) source leak.scm ERROR: In procedure register-command!: In procedure gdbscm_register_command_x: Out of range: 'break' is not a prefix command in position 1: "break cmd" Error while executing Scheme code. Running this under valgrind reveals a memory leak for 'result' and 'prefix_text' from gdbscm_parse_command_name. Another leak can be revealed with this input script: (use-modules (gdb)) (register-command! (make-command "unknown-prefix cmd" #:command-class COMMAND_OBSCURE #:invoke (lambda (self arg from-tty) (display "Hello World")))) This one occurs earlier in gdbscm_parse_command_name, and now only 'result' leaks. The problem is that, when guile throws an exception then a longjmp is performed from the function that raise the exception back to the guile run-time. A consequence of this is that no function local destructors will be run. In gdbscm_parse_command_name, this means that the two function locals `result` and `prefix_text` will not have their destructors run, and any memory managed by these objects will be leaked. Fix this by assigning nullptr to these two function locals before throwing an exception. This will cause the managed memory to be deallocated. I could have implemented a fix that made use of Guile's dynwind mechanism to register a cleanup callback, however, this felt like overkill. At the point the exception is being thrown we know that we no longer need the managed memory, so we might as well just free the memory at that point. With this fix in place, the two leaks are now fixed in the valgrind output. Approved-By: Tom Tromey <tom@tromey.com>
2025-06-06gdb/python/guile: remove some explicit calls to xmallocAndrew Burgess2-9/+7
In gdbpy_parse_command_name (python/py-cmd.c) there is a call to xmalloc that can easily be replaced with a call to make_unique_xstrndup, which makes the code easier to read (I think). In gdbscm_parse_command_name (guile/scm-cmd.c) the same fix can be applied to remove an identical xmalloc call. And there is an additional xmalloc call, which can also be replaced with make_unique_xstrndup in the same way. The second xmalloc call in gdbscm_parse_command_name was also present in gdbpy_parse_command_name at one point, but was replaced with a use of std::string by this commit: commit 075c55e0cc0a68eeab777027213c2f545618e844 Date: Wed Dec 26 11:05:57 2018 -0700 Remove more calls to xfree from Python I haven't changed the gdbscm_parse_command_name to use std::string though, as that doesn't work well with the guile exception model. Guile exceptions work by performing a longjmp from the function that raises the exception, back to the guile run-time. The consequence of this is that destructors are not run. For example, if gdbscm_parse_command_name calls gdbscm_out_of_range_error, then any function local objects in gdbscm_parse_command_name will not have their destructors called. What this means is that, for the existing `result` and `prefix_text` locals, any allocated memory managed by these objects will be leaked if an exception is called. However, fixing this is pretty easy, one way is to just assign nullptr to these locals before raising the exception, this would cause the allocated memory to be released. But for std::string it is harder to ensure that the managed memory has actually been released. We can call std::string::clear() and then maybe std::string::shrink_to_fit(), but this is still not guaranteed to release any managed memory. In fact, I believe the only way to ensure all managed memory is released, is to call the std::string destructor. And so, for functions that can throw a guile exception, it is easier to just avoid std::string. As for the memory leak that I identify above; I'll fix that in a follow on commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-06-06gdb/solib: make _linker_namespace use selected frameGuinevere Larsen2-2/+8
When the convenience variable $_linker_namespace was introduced, I meant for it to print the namespace of the frame that where the user was stopped. However, due to confusing what "current_frame" and "selected_frame" meant, it instead printed the namespace of the lowermost frame. This commit updates the code to follow my original intent. Since the variable was never in a GDB release, updating the behavior should not cause any disruption. It also adds a test to verify the functionality. Approved-By: Tom Tromey <tom@tromey.com>
2025-06-06bfd: sframe: fix typo in commentsIndu Bhagat1-3/+3
bfd/ * elflink.c (elf_link_input_bfd): Replace ctf frame with SFrame.
2025-06-06gdb: unix: allow to use custom baud rateAlexey Lapshin4-7/+139
Modern unix systems allow to set custom baud rate instead of predefined in termios.h. - To use this in Linux it must have BOTHER macro in "asm/termio.h" - MacOS could handle this using IOSSIOSPEED passed to ioctl() Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I5bc95982f5d90c7030b73f484ecc0f75c060ebf7
2025-06-06gdb: unix: extend supported baudrate B_codesAlexey Lapshin1-0/+24
Added B_codes that may be supported in some unix systems Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I48624d6573dc6c72e26818dd44b24182c1dabb70
2025-06-06gdb/amd-dbgapi: remove one xfreeSimon Marchi1-2/+3
Replace a manual xfree with unique_xmalloc_ptr. Change-Id: Id4d2065e3294c4761fe3c852962360712b53d7a8 Approved-By: Tom Tromey <tom@tromey.com> Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
2025-06-06gdb/solib-rocm: remove one xfreeSimon Marchi1-2/+3
Replace a manual xfree with unique_xmalloc_ptr. Change-Id: I12a20106545905f1a80d069fc0555812cc3d6680 Approved-By: Tom Tromey <tom@tromey.com> Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
2025-06-06Fix regression with DW_AT_bit_offset handlingTom Tromey5-63/+115
Internal AdaCore testing using -gdwarf-4 found a spot where GCC will emit a negative DW_AT_bit_offset. However, my recent signed/unsigned changes assumed that this value had to be positive. I feel this bug somewhat invalidates my previous thinking about how DWARF attributes should be handled. In particular, both GCC and LLVM at understand that a negative bit offset can be generated -- but for positive offsets they might use a smaller "data" form, which is expected not to be sign-extended. LLVM has similar code but GCC does: if (bit_offset < 0) add_AT_int (die, DW_AT_bit_offset, bit_offset); else add_AT_unsigned (die, DW_AT_bit_offset, (unsigned HOST_WIDE_INT) bit_offset); What this means is that this attribute is "signed but default unsigned". To fix this, I've added a new attribute::confused_constant method. This should be used when a constant value might be signed, but where narrow forms (e.g., DW_FORM_data1) should *not* cause sign extension. I examined the GCC and LLVM DWARF writers to come up with the list of attributes where this applies, namely DW_AT_bit_offset, DW_AT_const_value and DW_AT_data_member_location (GCC only, but LLVM always emits it as unsigned, so we're safe here). This patch corrects the bug and imports the relevant test case. Regression tested on x86-64 Fedora 41. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680 Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-06-06gdb: prevent assertion after 'set debug breakpoint on'Andrew Burgess4-7/+118
Turns out that using 'set debug breakpoint on' will trigger an assertion for 'catch' style breakpoints, e.g.: (gdb) file /tmp/hello.x Reading symbols from /tmp/hello.x... (gdb) catch exec Catchpoint 1 (exec) (gdb) set debug breakpoint on (gdb) start [breakpoint] dump_condition_tokens: Tokens: { INFERIOR: "1" } Temporary breakpoint 2 at 0x401198: file /tmp/hello.c, line 18. [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT Starting program: /tmp/hello.x [breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT ../../gdb-16.1/gdb/gdbarch-gen.c:1764: internal-error: gdbarch_addr_bit: Assertion `gdbarch != NULL' failed. .... etc ... The problem is that catch breakpoints don't set the bp_location::gdbarch member variable, they a "dummy" location added with a call to add_dummy_location (breakpoint.c). The breakpoint_location_address_str function (which is only used for breakpoint debug output) relies on bp_location::gdbarch being set in order to call the paddress function. I considered trying to ensure that the bp_location::gdbarch variable is always set to sane value. For example, in add_dummy_location I tried copying the gdbarch from the breakpoint object, and this does work for the catchpoint case, but for some of the watchpoint cases, even the breakpoint object has no gdbarch value set. Now this seemed a little suspect, but, the more I thought about it, I wondered if "fixing" the gdbarch was allowing me to solve the wrong problem. If the gdbarch was set, then this would allow us to print the address field of the bp_location, which is going to be 0, after all, as this is a dummy location, which has no address. But does it really make sense to print the address 0? For some targets, 0 is a valid address. But that wasn't an address we actually selected, it's just the default value for dummy locations. And we already have a helper function bl_address_is_meaningful, which returns false for dummy locations. So, I propose that in breakpoint_location_address_str, we use bl_address_is_meaningful to detect dummy locations, and skip the address printing code in that case. For testing, I temporarily changed insert_bp_location so that breakpoint_location_address_str was always called, even when breakpoint debugging was off. I then ran the whole testsuite. Without the fixes included in this commit I saw lots of assertion failures, but with the fixes from this commit in place, I now see no assertion failures. I've added a new test which reveals the original assertion failure. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-06-06gdb/configure: Fix POSIX non-complianceGuinevere Larsen2-42/+29
My recent GDB commit: commit 4b42385c470c5f72f158f382f4d9c36f927aa84f Author: Guinevere Larsen <guinevere@redhat.com> Date: Wed Feb 12 08:25:46 2025 -0300 gdb: Make dwarf support optional at compile time Introduced a change that made the configure script not POSIX compliant, by using fallthrough in some case statements. This commit reworks that part of the change to only use if statements, so that no code is duplicated but things remain POSIX compliant. Reviewed-by: Sam James <sam@gentoo.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-06-06Make default_gdb_exit resilient to failed closesPedro Alves1-1/+3
For some reason, when testing GDB on Cygwin, I get: child process exited abnormally while executing "exec sh -c "exec > /dev/null 2>&1 && (kill -2 -$spid || kill -2 $spid)"" (procedure "close_wait_program" line 20) invoked from within "close_wait_program $shell_id $pid" (procedure "standard_close" line 23) invoked from within "standard_close "Windows-ROCm"" ("eval" body line 1) invoked from within "eval ${try}_${proc} \"$dest\" $args" (procedure "call_remote" line 42) invoked from within "call_remote "" close $host" (procedure "remote_close" line 3) invoked from within "remote_close host" (procedure "log_and_exit" line 30) invoked from within "log_and_exit" When that happens from within clean_restart, clean_restart doesn't clear the gdb_spawn_id variable, and then when clean_restart starts up a new GDB, that sees that gdb_spawn_id is already set, so it doesn't actually spawn a new GDB, and so clean_restart happens to reuse the same GDB (!). Many tests happen to actually work OK with this, but some don't, and the failure modes can be head-scratching. Of course, the failure to close GDB should be fixed, but when it happens, I think it's good to not end up with the current weird state. Connecting the "child process exit abnormally" errors at the end of a testcase run with weird FAILs in other testcases took me a while (as in, weeks!), it wasn't obvious to me immediately. Thus, this patch makes default_gdb_exit more resilient to failed closes, so that gdb_spawn_id is unset even is closing GDB fails, and we move on to start a new GDB. Approved-By: Andrew Burgess <aburgess@redhat.com> Change-Id: I9ec95aa61872a40095775534743525e0ad2097d2
2025-06-06gdb_test_multiple: Anchor prompt match if -lblPedro Alves3-1/+112
The testcase added by this patch has a gdb_test_multiple call that wants to match different lines of output that all have a common prefix, and do different actions on each. Instead of a single regular expression with alternatives, it's clearer code if the different expressions are handled with different "-re", like so: gdb_test_multiple "command" "" -lbl { -re "^command(?=\r\n)" { exp_continue } -re "^\r\nprefix foo(?=\r\n)" { # Some action for "foo". exp_continue } -re "^\r\nprefix bar(?=\r\n)" { # Some action for "bar". exp_continue } -re "^\r\nprefix \[^\r\n\]*(?=\r\n)" { # Some action for all others. exp_continue } -re "^\r\n$::gdb_prompt $" { gdb_assert {$all_prefixes_were_seen} $gdb_test_name } } Above, the leading anchors in the "^\r\nprefix..." matches are needed to avoid too-eager matching due to the common prefix. Without the anchors, if the expect output buffer happens to contain at least: "\r\nprefix xxx\r\nprefix foo\r\n" ... then the "prefix foo" pattern match inadvertently consumes the first "prefix xxx" line. Without the anchor in the prompt match, like: -re "\r\n$::gdb_prompt $" { gdb_assert {$all_prefixes_were_seen} $gdb_test_name } Or the equivalent: -re -wrap "" { gdb_assert {$all_prefixes_were_seen} $gdb_test_name } ... then if the expect buffer contains: "\r\nmeant-to-be-matched-by-lbl\r\nprefix foo\r\n$gdb_prompt " ... then the prompt regexp matches this, consuming the "prefix" line inadvertently, and we get a FAIL. The built-in regexp matcher for -lbl doesn't get a chance to match the "\r\nmeant-to-be-matched-by-lbl\r\n" part, because the built-in prompt match appears first within gdb_test_multiple. By adding the anchor to the prompt regexp, we avoid that problem. However, the same expect output buffer contents will still match the built-in prompt regexp. That is what is fixed by this patch. It makes it so that if -lbl is specified, the built-in prompt regexp has a leading anchor. Original idea for turning this into a gdb.testsuite/ testcase by Tom de Vries <tdevries@suse.de>. Approved-By: Tom de Vries <tdevries@suse.de> Change-Id: Ic2571ec793d856a89ee0d533ec363e2ac6036ea2
2025-06-06[gdb] Fix typo in gdb/break-catch-syscall.cTom de Vries1-1/+1
Fix typo "if the feature if supported" -> "if the feature is supported".
2025-06-06x86/Solaris: cope with new HANDLE_ALIGN behaviorJan Beulich1-1/+1
Extend the expectation adjustments done by 83d94ae428b1 ("tidy x86 HANDLE_ALIGN") to the Solaris clone of an affected testcase.
2025-06-06[gdb/testsuite] Fix timeout in gdb.multi/attach-while-running.expTom de Vries1-1/+1
With test-case gdb.multi/attach-while-running.exp usually I get: ... (gdb) run &^M Starting program: attach-while-running ^M (gdb) PASS: $exp: run & [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M add-inferior^M [New inferior 2]^M Added inferior 2 on connection 1 (native)^M (gdb) PASS: $exp: add-inferior ... or: ... (gdb) run & Starting program: attach-while-running (gdb) PASS: $exp: run & add-inferior [New inferior 2] Added inferior 2 on connection 1 (native) (gdb) PASS: $exp: add-inferior [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". ... but sometimes I run into: ... (gdb) run & Starting program: attach-while-running (gdb) PASS: $exp: run & add-inferior [New inferior 2] Added inferior 2 on connection 1 (native) (gdb) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". FAIL: $exp: add-inferior (timeout) ... Fix this by using -no-prompt-anchor. Tested on x86_64-linux.
2025-06-06[gdb/tdep] Don't call WaitForSingleObject with INFINITE argTom de Vries1-1/+6
I decided to try to build and test gdb on Windows. I found a page on the wiki [1] suggesting three ways of building gdb: - MinGW, - MinGW on Cygwin, and - Cygwin. I picked Cygwin, because I've used it before (though not recently). I managed to install Cygwin and sufficient packages to build gdb and start the testsuite. However, testsuite progress ground to a halt at gdb.base/branch-to-self.exp. [ AFAICT, similar problems reported here [2]. ] I managed to reproduce this hang by running just the test-case. I attempted to kill the hanging processes by: - first killing the inferior process, using the cygwin "kill -9" command, and - then killing the gdb process, likewise. But the gdb process remained, and I had to point-and-click my way through task manager to actually kill the gdb process. I investigated this by attaching to the hanging gdb process. Looking at the main thread, I saw it was stopped in a call to WaitForSingleObject, with the dwMilliseconds parameter set to INFINITE. The backtrace in more detail: ... (gdb) bt #0 0x00007fff196fc044 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/windows/SYSTEM32/ntdll.dll #1 0x00007fff16bbcdcf in WaitForSingleObjectEx () from /cygdrive/c/windows/System32/KERNELBASE.dll #2 0x0000000100998065 in wait_for_single (handle=0x1b8, howlong=4294967295) at gdb/windows-nat.c:435 #3 0x0000000100999aa7 in windows_nat_target::do_synchronously(gdb::function_view<bool ()>) (this=this@entry=0xa001c6fe0, func=...) at gdb/windows-nat.c:487 #4 0x000000010099a7fb in windows_nat_target::wait_for_debug_event_main_thread (event=<optimized out>, this=0xa001c6fe0) at gdb/../gdbsupport/function-view.h:296 #5 windows_nat_target::kill (this=0xa001c6fe0) at gdb/windows-nat.c:2917 #6 0x00000001008f2f86 in target_kill () at gdb/target.c:901 #7 0x000000010091fc46 in kill_or_detach (from_tty=0, inf=0xa000577d0) at gdb/top.c:1658 #8 quit_force (exit_arg=<optimized out>, from_tty=from_tty@entry=0) at gdb/top.c:1759 #9 0x00000001004f9ea8 in quit_command (args=args@entry=0x0, from_tty=from_tty@entry=0) at gdb/cli/cli-cmds.c:483 #10 0x000000010091c6d0 in quit_cover () at gdb/top.c:295 #11 0x00000001005e3d8a in async_disconnect (arg=<optimized out>) at gdb/event-top.c:1496 #12 0x0000000100499c45 in invoke_async_signal_handlers () at gdb/async-event.c:233 #13 0x0000000100eb23d6 in gdb_do_one_event (mstimeout=mstimeout@entry=-1) at gdbsupport/event-loop.cc:198 #14 0x00000001006df94a in interp::do_one_event (mstimeout=-1, this=<optimized out>) at gdb/interps.h:87 #15 start_event_loop () at gdb/main.c:402 #16 captured_command_loop () at gdb/main.c:466 #17 0x00000001006e2865 in captured_main (data=0x7ffffcba0) at gdb/main.c:1346 #18 gdb_main (args=args@entry=0x7ffffcc10) at gdb/main.c:1365 #19 0x0000000100f98c70 in main (argc=10, argv=0xa000129f0) at gdb/gdb.c:38 ... In the docs [3], I read that using an INFINITE argument to WaitForSingleObject might cause a system deadlock. This prompted me to try this simple change in wait_for_single: ... while (true) { - DWORD r = WaitForSingleObject (handle, howlong); + DWORD r = WaitForSingleObject (handle, + howlong == INFINITE ? 100 : howlong); + if (howlong == INFINITE && r == WAIT_TIMEOUT) + continue; ... with the timeout of 0.1 second estimated to be: - small enough for gdb to feel reactive, and - big enough not to consume too much cpu cycles with looping. And indeed, the test-case, while still failing, now finishes in ~50 seconds. While there may be an underlying bug that triggers this behaviour, the failure mode is so severe that I consider it a bug in itself. Fix this by avoiding calling WaitForSingleObject with INFINITE argument. Tested on x86_64-cygwin, by running the testsuite past the test-case. Approved-By: Pedro Alves <pedro@palves.net> PR tdep/32894 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32894 [1] https://sourceware.org/gdb/wiki/BuildingOnWindows [2] https://sourceware.org/pipermail/gdb-patches/2025-May/217949.html [3] https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitforsingleobject
2025-06-06Automatic date update in version.inGDB Administrator1-1/+1
2025-06-05gdb/solib-svr4: make svr4_info::debug_loader_name an std::stringSimon Marchi1-4/+3
Remove some manual memory management. Change-Id: I9c752d35a70e3659509fed57df1c9a8d27ecc742 Approved-By: Tom Tromey <tom@tromey.com>
2025-06-05gdb/solib: rename convenience variable to _linker_namespaceGuinevere Larsen5-15/+15
Based on feedback from IRC and PR solib/32959, this commit renames the recently introduced convenience variable $_current_linker_namespace to the shorter name $_linker_namespace. This makes it more in line with existing convenience variables such as $_thread and $_inferior, and faster to type. It should be ok to simply change the name because the variable was never released to the public, so there should be no existing scripts depending on the name. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32959 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2025-06-05gdb/solib: Change type of convenience variable _current_linker_namespaceGuinevere Larsen4-17/+15
Based on IRC feedback since commit 6a0da68c036a85a46415aa0dada2421eee7c2269 gdb: add convenience variables around linker namespace debugging This commit changes the type of the _current_linker_namespace variable to be a simple integer. This makes it easier to use for expressions, like breakpoint conditions or printing from a specific namespace once that is supported, at the cost of making namespace IDs slightly less consistent. This is based on PR solib/32960, where no negative feedback was given for the suggestion. The commit also changes the usage of "linkage namespaces" to "linker namespaces" in the NEWS file, to reduce chance of confusion from an end user. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32960 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-06-05[gdb/testsuite] Fix gdb.base/bp-permanent.exp with gcc 15Tom de Vries1-1/+1
With test-case gdb.base/bp-permanent.exp and gcc 15 I run into: ... gdb compile failed, bp-permanent.c: In function 'test_signal_nested': bp-permanent.c:118:20: error: passing argument 2 of 'signal' from \ incompatible pointer type [-Wincompatible-pointer-types] 118 | signal (SIGALRM, test_signal_nested_handler); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | | | void (*)(void) In file included from bp-permanent.c:20: /usr/include/signal.h:88:57: note: expected '__sighandler_t' \ {aka 'void (*)(int)'} but argument is of type 'void (*)(void)' ... Fix this by adding an int parameter to test_signal_nested_handler. Tested on x86_64-linux. PR testsuite/32756 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32756
2025-06-05Automatic date update in version.inGDB Administrator1-1/+1
2025-06-04libctf: use __attribute__((__gnu_printf__)) where appropriateNick Alcock1-0/+5
We don't use any GNU-specific printf args, but this prevents warnings about %z, observed on MinGW even though every libc anyone is likely to use there supports %z perfectly well, and we're not stopping using it just because MinGW complains. Doing this means we stand more chance of seeing *actual* problems on such platforms without them being drowned in noise. We turn this off on clang, which doesn't support __gnu_printf__. Suggested by Eli Zaretskii. libctf/ PR libctf/31863 * ctf-impl.h (_libctf_printflike_): Use __gnu_printf__.
2025-06-04libctf, dedup: reclaim space wasted by duplicate hidden typesNick Alcock1-12/+28
In normal deduplicating links, we insert every type (identified by its unique hash) precisely once. But conflicting types appear in multiple dicts, so for those, we loop, inserting them into every target dict in turn (each corresponding to an input dict that type appears in). But in cu-mapped links, some of those dicts may have been merged into one: now that we are hiding duplicate conflicting types more aggressively in such links, we are getting duplicate identical hidden types turning up in large numbers. Fix this by eliminating them in cu-mapping phase 1 (the phase in which this merging takes place), by checking to see if a type with this hash has already been inserted in this dict and skipping it if so. This is redundant and a waste of time in other cu-mapping phases and in normal links, but in cu-mapped links it saves a few tens to hundreds of kilobytes in kernel-sized links. libctf/ PR libctf/33047 * ctf-dedup.c (ctf_dedup_emit_type): Check for already-emitted types in cu-mapping phase 1.
2025-06-04libctf: dedup: preserve non-root flag across normal linksNick Alcock6-56/+322
The previous commits dropped preservation of the non-root flag in ctf_link and arranged to use it somewhat differently to track conflicting types in cu-mapped CUs when doing cu-mapped links. This was necessary to prevent entirely spuriously hidden types from appearing on the output of such links. Bring it (and the test for it) back. The problem with the previous design was that it implicitly assumed that the non-root flag it saw on the input was always meant to be preserved (when in the final phase of cu-mapped links it merely means that conflicting types were found in intermediate links), and also that it could figure out what the non-root flag on the input was by sucking in the non-root flag of the input type corresponding to an output in the output mapping (which maps type hashes to a corresponding type on some input). This method of getting properties of the input type *does* work *if* that property was one of those hashed by the ctf_dedup_hash_type process. In that case, every type with a given hash will have the same value for all hashed-in properties, so it doesn't matter which one is consulted (the output mapping points at an arbitrary one of those input types). But the non-root flag is explicitly *not* hashed in: as a comment in ctf_dedup_rhash_type notes, being non-root is not a property of a type, and two types (one non-root, one not) can perfectly well be the same type even though one is visible and one isn't. So just copying the non-root flag from the output mapping's idea of the input type will copy in a value that is not stabilized by the hash, so is more-or-less random! So we cannot do that. We have to do something else, which means we have to decide what to do if two identical types with different nonroot flag values pop up. The most sensible thing to do is probably to say that if all instances of a type are non-root-visible, the linked output should also be non-root-visible: any root-visible types in that set, and the output type is root-visible again. We implement this with a new cd_nonroot_consistency dynhash, which maps type hashes to the value 0 ("all instances root-visible"), 1 ("all instances non-root-visible") or 2 ("inconsistent"). After hashing is over, we save a bit of memory by deleting everything from this hashtab that doesn't have a value of 1 ("non-root-visible"), then use this to decide whether to emit any given type as non-root-visible or not. However... that's not quite enough. In cu-mapped links, we want to disregard this whole thing because we just hide everything -- but in phase 2, when we take the smushed-together CUs resulting from phase 1 and deduplicate them against each other, we want to do what the previous commits implemented and ignore the non-root flag entirely, instead falling back to preventing clashes by hiding anything that would be considered conflicting. We extend the existing cu_mapped parameter to various bits of ctf_dedup so that it is now tristate: 0 means a normal link, 1 means the smush-it- together phase of cu-mapped links, and 2 means the final phase of cu-mapped links. We do the hide-conflicting stuff only in phase 2, meaning that normal links by GNU ld can always respect the value of the nonroot flag put on types in the input. (One extra thing added as part of this: you can now efficiently delete the last value returned by ctf_dynhash_next() by calling ctf_dynhash_next_remove.) We bring back the ctf-nonroot-linking test with one tweak: linking now works on mingw as long as you're using the ucrt libc, so re-enable it for better test coverage on that platform. libctf/ PR libctf/33047 * ctf-hash.c (ctf_dynhash_next_remove): New. * ctf-impl.h (struct ctf_dedup) [cd_nonroot_consistency]: New. * ctf-link.c (ctf_link_deduplicating): Differentiate between cu-mapped and non-cu-mapped links, even in the final phase. * ctf-dedup.c (ctf_dedup_hash_type): Callback prototype addition. Get the non-root flag and pass it down. (ctf_dedup_rhash_type): Callback prototype addition. Document restrictions on use of the nonroot flag. (ctf_dedup_populate_mappings): Populate cd_nonroot_consistency. (ctf_dedup_hash_type_fini): New function: delete now-unnecessary values from cd_nonroot_consistency. (ctf_dedup_init): Initialize it. (ctf_dedup_fini): Destroy it. (ctf_dedup): cu_mapping is now cu_mapping_phase. Call ctf_dedup_hash_type_fini. (ctf_dedup_emit_type): Use cu_mapping_phase and cd_nonroot_consistency to propagate the non-root flag into outputs for normal links, and to do name-based conflict checking only for phase 2 of cu-mapped links. (ctf_dedup_emit): cu_mapping is now cu_mapping_phase. Adjust assertion accordingly. * testsuite/libctf-writable/ctf-nonroot-linking.c: Bring back. * testsuite/libctf-writable/ctf-nonroot-linking.lk: Likewise.
2025-06-04libctf: dedup: improve hiding of conflicting types in the same dictNick Alcock1-5/+40
If types are conflicting, they are usually moved into separate child dicts -- but not always. If they are added to the same dict by the cu-mapping mechanism (as used e.g. for multi-TU kernel modules), we can easily end up adding multiple conflicting types with the same name to the same dict. The mechanism used for turning on the non-root-visible flag in order to do this had a kludge attached which always hid types with the same name, whether or not they were conflicting. This is unnecessary and can hide types that should not be hidden, as well as hiding bugs. Remove it, and replace it with two different approaches: - for everything but cu-mapped links (the in-memory first phase of a link with ctf_link_add_cu_mapping in force), check for duplicate names if types are conflicting, and mark them as hidden if the names are found. This will never happen in normal links (in an upcoming commit we will suppress doing even this much in such cases). - for cu-mapped links, the only case that merges multiple distinct target dicts into one, we apply a big hammer and simply hide everything! The non-root flag will be ignored in the next link phase anyway (which dedups the cu-mapped pieces against each other), and this way we can be sure that merging multiple types cannot incur name clashes at this stage. The result seems to work: the only annoyance is that when enums with conflicting enumerators are found in a single cu-mapped child (so, really multiple merged children), you may end up with every instance of that enum being hidden for reasons of conflictingness. I don't see a real way to avoid that. libctf/ PR libctf/33047 * ctf-dedup.c (ctf_dedup_emit_type): Only consider non conflicting types. Improve type hiding in the presence of clashing enumerators. Hide everything when doing a cu-mapped link: they will be unhidden by the next link pass if nonconflicting.
generated by cgit v1.1 at 2025-07-10 21:32:59 +0000