aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2025-01-29gdb/testsuite: add comments to line table from DWARF assemblerAndrew Burgess1-7/+7
Add comments to the assembler generated by the DWARF assembler that builds the line table. I found these comments useful when debugging issues with the line table parsing. This patch should make no difference to what is being tested. The test binaries should be unchanged after this commit. Approved-By: Kevin Buettner <kevinb@redhat.com>
2025-01-29gdb: move debug output inside block in dwarf_record_line_1Andrew Burgess1-8/+7
The debug output that says a line has been recorded is currently outside the `if` block which decides if the line should be recorded or not. This means the debug output will claim the line was recorded, when actually it wasn't! Fixed by moving the debug output inside the `if` block. Should be no user visible changes after this commit (except if debug output is turned on). Approved-By: Tom Tromey <tom@tromey.com>
2025-01-28MicroBlaze: Add features/microblaze-linux.xmlMichael J. Eager4-0/+157
This is a preparatory patch to support native linux port of gdbserver for MicroBlaze * gdb/features/Makefile : Add microblaze-expedite * gdb/features/microblaze-linux.xml : New * gdb/features/microblaze-linux.c : New (generated) * gdb/regformats/microblaze-linux.dat : New (generated) Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com> Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com> Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com> Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com> Signed-off-by: Michael J. Eager <eager@eagercon.com>
2025-01-28[gdb/tui] Fix assert in tui_source_window_base::refresh_windowTom de Vries2-0/+6
Say we use the executable of test-case gdb.tui/tui-missing-src.exp like this: ... $ gdb.sh -q -tui outputs/gdb.tui/tui-missing-src/tui-missing-src \ -ex "b f2"\ -ex run ... (from a directory not containing a file called main.c to make sure that the missing source stays missing) and then issue finish: ... (gdb) finish Run till exit from #0 f2 (x=4) at f2.c:5 0x0000000000400570 in main () at main.c:7 Value returned is $1 = 13 (gdb) ... and use control-<minus> to decrease the font size (IOW increase the $LINES and $COLUMNS) on the terminal, we get: ... gdb/tui/tui-winsource.c:340: internal-error: refresh_window: \ Assertion `pad_x + view_width <= pad_width || m_pad.get () == nullptr' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. ... The tui_source_window_base class has variable m_pad which keeps track of a curses pad that is used to display the source code or disassembly efficiently. The assert in tui_source_window_base::refresh_window triggers while preparing to display part of the pad. The problem is that the window is in a state in which the pad is not used, because m_content.empty () == true. Instead, it simply shows "[ No Source Available ]". Fix this by bailing out of tui_source_window_base::refresh_window before accessing the m_pad variable, if m_content.empty () == true. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR tui/32592 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32592
2025-01-28[gdb/guile] Use SCM_DEBUG_TYPING_STRICTNESS 0Tom de Vries1-11/+18
I build gdb with libguile v2.0.9, and ran into: ... In file included from /usr/include/guile/2.0/libguile.h:56, from ../../gdb/guile/guile-internal.h:30, from ../../gdb/guile/scm-arch.c:26: /usr/include/guile/2.0/libguile/inline.h: In function 'int scm_is_pair(SCM)': /usr/include/guile/2.0/libguile/tags.h:97:53: error: \ operation on '*0' may be undefined [-Werror=sequence-point] # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(SCM*)0=(x)): x)) ~~~~~~~~~^~~~~ ... Fix this by using SCM_DEBUG_TYPING_STRICTNESS 0. We were already using this for c++20 due to a Werror=volatile in SCM_UNPACK when using libguile v2.0.10. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-01-28Fix gdb.ada/import.exp when using moldTom Tromey4-9/+10
We found that the gdb.ada/import.exp test fails when 'mold' is used as the linker. This happens because mold decides to mark most of the symbols in the executable as being file-local. I tend to think this choice, while non-traditional, is probably fine. So, this patch fixes the problem by changing the relevant Ada code to look for file-local symbols as well. Furthermore, there are two overloads of lookup_minimal_symbol_linkage that both have a final 'bool' parameter -- but with radically different meanings. This patch somewhat clears up this confusion as well. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31378
2025-01-28gdb/remote: add 'binary-upload' feature to guard 'x' packet useAndrew Burgess3-0/+21
This mailing list discussion: https://inbox.sourceware.org/gdb-patches/CAOp6jLYD0g-GUsx7jhO3g8H_4pHkB6dkh51cbyDT-5yMfQwu+A@mail.gmail.com highlighted the following issue with GDB's 'x' packet implementation. Unfortunately, LLDB also has an 'x' packet, but their implementation is different to GDB's and so targets that have implemented LLDB's 'x' packet are incompatible with GDB. The above thread is specifically about the 'rr' tool, but there could be other remote targets out there that have this problem. The difference between LLDB and GDB is that GDB expects a 'b' prefix on the reply data, while LLDB does not. The 'b' is important as it allows GDB to distinguish between an empty reply (which will be a 'b' prefix with no trailing data) and an unsupported packet (which will be a completely empty packet). It is not clear to me how LLDB distinguishes these two cases. See for discussion of the 'x' packet: https://inbox.sourceware.org/gdb-patches/cover.1710343840.git.tankut.baris.aktemur@intel.com/#r with the part specific to the 'b' marker in: https://inbox.sourceware.org/gdb-patches/87msq82ced.fsf@redhat.com/ I propose that we add a new feature 'binary-upload' which can be reported by a stub in its qSupported reply. By default this feature is "off", meaning GDB will not use the 'x' packet unless a stub advertises this feature. I have updated gdbserver to send 'binary-upload+', and when I examine the gdbserver log I can see this feature being sent back, and then GDB will use the 'x' packet. When connecting to an older gdbserver, the feature is not sent, and GDB does not try to use the 'x' packet at all. I also built the latest version of `rr` and tested using current HEAD of master, where I see problems like this: (rr) x/10i main 0x401106 <main>: Cannot access memory at address 0x401106 Then tested using this patched version of GDB, and now I see: (rr) x/10i main 0x401106 <main>: push %rbp 0x401107 <main+1>: mov %rsp,%rbp 0x40110a <main+4>: mov 0x2f17(%rip),%rax # 0x404028 <global_ptr> ... etc ... and looking in the remote log I see GDB is now using the 'm' packet instead of the 'x' packet. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32593 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
2025-01-28gdb/configure: fail configure if all targets requested with 32bit bfdGuinevere Larsen2-2/+6
As PR sim/28684 explains, it isn't possible to compile GDB with all targets enabled and not enabling 64 bit bfd. In 64 bit hosts, 64 bit bfd is forced, so the build works, but in 32 bit hosts, that has to be explicitly enabled. I ran into this when I tried compiling GDB on a mips64 machine running a 32 bit OS. Along with the errors in the PR, several other architectures are also required, notably aarch64 and other explicitly 64bit targets. Additionally, some 32 bit files required for the gdb mips target aren't added to the makefile. Considering the last comment in the bug says this isn't going to be fixed on the binutils side, I didn't think it was worth trying to fix the GDB side. Instead, this commit causes the configure script to fail if all targets were requested and 64 bit bfd isn't enabled. If that is ever fixed, we can revert this commit. I considered adding this to the top level configure script, but couldn't figure out how to detect the situation in there, so this was my next best idea. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28684 Approved-by: Kevin Buettner <kevinb@redhat.com>
2025-01-28[gdb/doc] Fix "Standard Replies" xrefTom de Vries1-1/+1
When building gdb with an older makeinfo (4.13), I run into: ... gdb/doc/gdb.texinfo:42613: warning: `.' or `,' must follow @xref, not `f'. ... This is related to this line: ... @xref{Standard Replies} for standard error responses, and how to respond indicating a command is not supported. ... Fix this by adding a comma. Tested by rebuilding the docs. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
2025-01-27[gdb/build] Fix build with gcc 7.5.0Tom de Vries1-0/+5
When building gdb with gcc 7.5.0, I run into: ... gdb/dwarf2/cooked-index.c: In lambda function: gdb/dwarf2/cooked-index.c:104:5: error: \ the value of ‘_sch_tolower’ is not usable in a constant expression }; ^ In file included from gdbsupport/gdb-safe-ctype.h:47:0, from gdb/dwarf2/cooked-index.c:34: include/safe-ctype.h:111:29: note: ‘_sch_tolower’ was not declared ‘constexpr’ extern const unsigned char _sch_tolower[256]; ^~~~~~~~~~~~ ... This does not happen with gcc 8.2.1. Fix this by dropping the constexpr on lambda function munge in cooked_index_entry::compare for gcc 7. Tested by completing the build on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-01-27[gdb/doc] Use more lower-case in @sc in the documentationTom de Vries2-2/+2
When building gdb with an older makeinfo (4.13), I run into: ... gdb/doc/gdb.texinfo:49064: warning: @sc argument all uppercase, thus no effect. ... Using a grep, I found one more instance: ... $ grep @sc gdb/doc/*.tex* | egrep -v '@sc{[^A-Z]*}' gdb/doc/gdb.texinfo:\ Bit 1 (@sc{ZA}) shows whether the @code{ZA} register state is active (in use) or gdb/doc/python.texi:\ corresponding @sc{GDB/MI} command's output. Refer to the ... Fix this by using lowercase letters in the @sc argument, similar to how that was done in commit c96452ad168 ("Use lower-case in @sc in the documentation"). Tested by rebuilding the documentation.
2025-01-27[gdb/doc] Fix qIsAddressTagged anchorTom de Vries1-1/+1
When building gdb with an older makeinfo (4.13), I run into: ... gdb/doc/gdb.texinfo:44159: @anchor expected braces. gdb/doc/gdb.texinfo:44159: ` {qIsAddressTagged} ... This is related to this line: ... @anchor {qIsAddressTagged} ... Fix this by removing the space before the left brace. Tested by rebuilding the documentation.
2025-01-27[gdb/doc] Fix gdb.unwinder docsTom de Vries1-2/+2
When building gdb with an older makeinfo (4.13), I run into: ... gdb/doc/python.texi:3015: warning: `(' follows defined name \ `gdb.unwinder.Unwinder.__init__' instead of whitespace. gdb/doc/python.texi:3041: warning: `(' follows defined name \ `gdb.unwinder.FrameId.__init__' instead of whitespace. ... The warnings are related to these two lines: ... @defun gdb.unwinder.Unwinder.__init__(name) ... @defun gdb.unwinder.FrameId.__init__(sp, pc, special = @code{None}) ... Indeed, when checking the command and variable index, we can see that it contains an incorrect entry: ... gdb.unwinder.FrameId.__init__(sp,: Unwinding Frames in Python ... Fix this by adding a space before the left parenthesis. Tested by rebuilding the documentation and checking the command and variable index.
2025-01-27Fix some broken links in docs and commentsYury Khrustalev1-1/+1
Reviewed-By Richard Earnshaw <richard.earnshaw@arm.com>
2025-01-24Fix C++ template function matching in cooked indexTom Tromey4-28/+53
In commit 64a97606 ("Support template lookups in strncmp_iw_with_mode"), gdb was changed so that a command like "break func<templ>" would match instantiations like "func<templ<int>>". The new indexer does not support this and so this is a regression. This went unnoticed because gdb.linespec.cpcompletion.exp puts all these functions into the main file, and this CU is expanded early. This patch fixes the bug by changing the cooked index entry comparison function. It also updates the test to fail without this fix. Regression tested on x86-64 Fedora 40. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32482
2025-01-24gdb/riscv: Add command to switch between numeric & abi register namesCiaran Woodward3-27/+86
In RISC-V, the general registers can be shown in their abi form (e.g. sp, a0) or their numeric form (e.g. x2, x10). Depending on context/preference, someone may prefer to see one form over the other. The disassembler already supports this configuration, which can be changed using the 'set disassembler-options numeric' command. This commit adds a new set/show command to change gdb's preference: 'set riscv numeric-registers-names on/off'. If on, 'info registers' and other situations will print the numeric register names, rather than the abi versions. The alias generation has been modified so that the abi versions are still available for access if specifically requested such as 'print $ra'. This was done by changing the behaviour of the code which adds the aliases: all register names will be added as aliases, even if the name is the primary one. There is also no functional downside to adding aliases which are surplus-to-requirement, since they will be ignored if there is a 'true' register with the same name. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-24[gdb/tdep] Fix gdb.ada/O2_float_param.exp on s390x-linuxTom de Vries1-0/+16
With test-case gdb.ada/O2_float_param.exp on s390x-linux, I get: ... (gdb) frame^M #0 callee.increment (val=99.0, val@entry=<error reading variable: \ register has not been saved in frame>, msg=...) at callee.adb:19^M 19 procedure Increment (Val : in out Float; Msg: String) is^M (gdb) FAIL: $exp: scenario=all: frame ... The frame command calls read_frame_arg to get: - the current value of val, and - the value of val at function entry. The first scenario succeeds, and the second scenario fails. For context and contrast, let's also investigate the first scenario: getting the current value of val. Function parameter val: ... <2><b51>: Abbrev Number: 4 (DW_TAG_formal_parameter) <b52> DW_AT_name : val <b58> DW_AT_type : <0xb86> <b5c> DW_AT_location : 0xab (location list) ... has location list: ... 000000ab 0000000001002928 0000000001002967 (DW_OP_reg16 (f0)) 000000be 0000000001002967 0000000001002968 (DW_OP_reg24 (f8)) 000000d1 0000000001002968 0000000001002974 (DW_OP_GNU_regval_type: 24 (f8) <0xb29>; DW_OP_GNU_const_type: <0xb29> 4 byte block: 3f 80 0 0 ; DW_OP_plus; DW_OP_stack_value) 000000ef 0000000001002974 0000000001002982 (DW_OP_GNU_entry_value: (DW_OP_GNU_regval_type: 16 (f0) <0xb29>); DW_OP_GNU_const_type: <0xb29> 4 byte block: 3f 80 0 0 ; DW_OP_plus; DW_OP_stack_value) 0000010f <End of list> ... and since we're stopped at address 0x1002928: ... (gdb) print $pc $1 = (access procedure) 0x1002928 <callee.increment> ... we get the value from dwarf register 16. The s390x ABI [1] specifies that dwarf register 16 maps onto 8-byte register f0 or 16-byte register v0 (where f0 is part of v0), and in this case (because the v0 register is available) s390_dwarf_reg_to_regnum maps it to v0. Val is only 4 bytes: ... (gdb) ptype val type = <4-byte float> ... and s390_value_from_register takes care to get the value from the correct part of v0. The value of v0 is found in the prologue cache, and the value of parameter val is printed. Now the second scenario: getting the value of val at function entry. FWIW, since we're stopped at function entry, we could simply return the same value, reading the same register, but that's currently not implemented [2]. Instead we start from the fact that val is in dwarf reg 16 at function entry, and then use call site information: ... <4><cf7>: Abbrev Number: 13 (DW_TAG_GNU_call_site) <cf8> DW_AT_low_pc : 0x1002a46 <d00> DW_AT_abstract_origin: <0xdda> <5><d04>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter) <d05> DW_AT_location : 1 byte block: 60 (DW_OP_reg16 (f0)) <d07> DW_AT_GNU_call_site_value: 3 byte block: f5 18 2d \ (DW_OP_GNU_regval_type: 24 (f8) <0xc42>) <5><d0b>: Abbrev Number: 12 (DW_TAG_GNU_call_site_parameter) ... to conclude that the value we're looking for is in dwarf reg 24, which s390_dwarf_reg_to_regnum maps to v8. As before, s390_value_from_register takes care to get the value from the correct part of v8. However, v8 is not available in the prologue cache, and we take a different path and end up in s390_unwind_pseudo_register, where v8 and similar (regnum_is_vxr_full) is unhandled, and we get: ... return value::allocate_optimized_out (type); ... which eventually causes the "error reading variable: register has not been saved in frame". Fix this by handling the regnum_is_vxr_full case in s390_unwind_pseudo_register, similar to how that is done in s390_pseudo_register_read. Tested on s390x-linux. This also fixes test-case gdb.base/savedregs.exp. [1] https://github.com/IBM/s390x-abi [2] https://sourceware.org/pipermail/gdb-patches/2024-September/211589.html
2025-01-24[gdb/testsuite] Record less in gdb.reverse/time-reverse.expTom de Vries2-4/+15
While stepping through gdb.reverse/time-reverse.exp I realized that we're recording the instructions for resolving the PLT entries for functions time and syscall, while that's not really the focus of the test-case. Limit the scope of the test, by calling the functions once before starting to record. Also call "info record" after recording to make it clear how many instructions were recorded. On x86_64-linux, before this patch (but with info record added), we have: ... $ grep "Log contains" gdb.log Log contains 750 instructions. Log contains 1218 instructions. ... and with this patch we have: ... $ grep "Log contains" gdb.log Log contains 24 instructions. Log contains 19 instructions. ... Tested on x86_64-linux. Approved-By: Guinevere Larsen <guinevere@redhat.com>
2025-01-23[gdb/cli] Fix return from frame containing inline frameTom de Vries3-1/+83
Consider test-case gdb.base/return-3.exp: ... $ gdb -q outputs/gdb.base/return-3/return-3 Reading symbols from outputs/gdb.base/return-3/return-3... (gdb) ... Function bar is an inlined function, and consequently we cannot return from it: ... (gdb) b bar Breakpoint 1 at 0x4006ac: file return-3.c, line 25. (gdb) r Starting program: return-3 ... Breakpoint 1, bar () at return-3.c:25 25 c++; (gdb) return Can not force return from an inlined function. (gdb) ... However, function foo is not an inline function, and we should be able to return from it, but we get the same error message: ... (gdb) up 31 bar (); (gdb) return Can not force return from an inlined function. (gdb) ... Fix this by using the selected frame rather than the current frame in return_command, such that we get instead: ... (gdb) up 31 bar (); (gdb) return 40 printf ("%d\n", c); (gdb) ... Tested on aarch64-linux. Reviewed-By: Guinevere Larsen <guinevere@redhat.com> PR cli/32479 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32479
2025-01-22Remove gnatmake_version_at_leastTom Tromey5-25/+4
This removes gnatmake_version_at_least in favor of using the more flexible gnat_version_compare. I think these two version numbers should be the same, as gnatmake is shipped with the compiler.
2025-01-22Avoid crash with 'lengthTom Tromey5-2/+106
While testing gnat-llvm, I found a gdb crash when applying 'length to a non-array type. This patch fixes the crash.
2025-01-22Preserve local variables in another Ada test caseTom Tromey3-2/+45
I found another Ada test case where gnat-llvm optimizes away the local variables. This patch applies the same fix to it as previous patches.
2025-01-22[gdb/testsuite] Fix gdb.base/branch-to-self.exp on arm-linuxTom de Vries1-1/+16
On arm-linux (ubuntu 24.04 with gcc 13.3.0) with target board unix/-marm and test-case gdb.base/branch-to-self.exp I run into: ... (gdb) continue^M Continuing.^M ^M Breakpoint 2, main () at branch-to-self.c:38^M 38 for (;;); /* loop-line */^M (gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint si^M 0x0040058c 38 for (;;); /* loop-line */^M (gdb) FAIL: $exp: single-step: si ... In contrast, on the same machine but with debian testing and gcc 14.2.0 we have: ... (gdb) continue^M Continuing.^M ^M Breakpoint 2, main () at branch-to-self.c:38^M 38 for (;;); /* loop-line */^M (gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint si^M ^M Breakpoint 2, main () at branch-to-self.c:38^M 38 for (;;); /* loop-line */^M (gdb) PASS: $exp: single-step: stepi ... The difference is in the instruction(s) generated for the loop. In the passing case, we have: ... 588: eafffffe b 588 <main+0x24> ... and in the failing case: ... 588: e320f000 nop {0} 58c: eafffffd b 588 <main+0x24> ... The purpose of this part of the test-case is to: - generate a branch instruction that jumps to itself, and - set a breakpoint on it, and check that stepi-ing from that breakpoint triggers the breakpoint again. As we can see, in the failing case we failed to generate a branch instruction that jumps to itself, and consequently we cannot expect to hit the breakpoint again after issuing a single si. Fix this by issuing stepi until we hit the breakpoint. Tested on arm-linux. Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2025-01-21[gdb/symtab] Fix gdb.base/fission-macro.exp with unix/-m32Tom de Vries2-3/+17
When running test-case gdb.base/fission-macro.exp on openSUSE Tumbleweed (using gcc 14) with target board unix/-m32, I get: ... (gdb) info macro FIRST^M Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:0^M -DFIRST=1^M (gdb) FAIL: $exp: \ dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST ... instead of the expected: ... (gdb) info macro FIRST^M Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:18^M (gdb) PASS: $exp: \ dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST ... A dwarf-5 .debug_str_offsets section starts with a header consisting of: - an initial length (4 bytes for 32-bit and 12 bytes for 64-bit), - a 2 byte version string, and - 2 bytes padding so in total 8 bytes for 32-bit and 16 bytes for 64-bit. This offset is calculated here in dwarf_decode_macros: ... str_offsets_base = cu->header.addr_size; ... which is wrong for both dwarf-5 cases (and also happens to be wrong for dwarf-4). Fix this by computing str_offsets_base correctly for dwarf-5, for both the 32-bit and 64-bit case. Likewise, fix this for dwarf-4, using str_offsets_base 0. We can only test this with gcc-15, because gcc 14 and earlier don't have the fix for PR debug/115066. Tested on x86_64-linux. Tested test-case using a current gcc trunk build, and gcc 14. Approved-By: Tom Tromey <tom@tromey.com> PR symtab/31897 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31897
2025-01-21[gdb/testsuite] Use -g3 in gdb.base/lineinc.expTom de Vries1-1/+2
The stated intention of test-case gdb.base/lineinc.exp is: ... # Test macro handling of #included files. ... However, the test-case does not produce any macro debug information. Fix this by adding macros in the compilation flags. Tested on x86_64-linux.
2025-01-20gdb/testsuite: Fix file location for gdb.base/backtrace-through-cu-nodebugGuinevere Larsen1-7/+7
The newly added test gdb.base/backtrace-through-cu-nodebug.exp had a problem in the call to gdb_compile, that caused the .o files to be outputted in the GDB file tree. This commit fixes the issues in the calls. Reported-By: Tom de Vries <tdevries@suse.de> Approved-By: Tom de Vries <tdevries@suse.de>
2025-01-20[gdb/testsuite] Fix gdb.cp/non-trivial-retval.exp on arm-linux with gcc 13Tom de Vries1-6/+22
On arm-linux, with target board unix/-mthumb, we get: ... (gdb) PASS: gdb.cp/non-trivial-retval.exp: continue to breakpoint: Break here p f1 (i1, i2)^M $1 = {a = -136274256}^M (gdb) FAIL: gdb.cp/non-trivial-retval.exp: gdb-command<p f1 (i1, i2)> ... This is not a problem with the inferior call, which works fine: ... (gdb) p f1 (23, 100) $3 = {a = 123} ... but instead it's a problem with the location information: ... (gdb) p i1 $1 = -136274356 (gdb) p i2 $2 = 100 ... which tells us to find the value of i1 in (DW_OP_fbreg: -12). The test-case passes if we drop -fvar-tracking, in which case the debug info tells us to find the value of i1 in (DW_OP_fbreg: -20). This is with gcc 13.3.0 on Ubuntu 24.04. With gcc 14.2.0 on Debian testing, the code is the same, but -fvar-tracking does use the correct '(DW_OP_fbreg: -20)'. There seems to be some bugfix in -fvar-tracking for gcc 14. Workaround the bug by using constants 23 and 100 instead of i1 and i2 when using -fvar-tracking and gcc < 14. Tested on arm-linux. PR testsuite/32549 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32549
2025-01-17Simplify get_frame_unwind_tableTom Tromey1-9/+4
This simplifies get_frame_unwind_table, changing it to use the registry 'emplace' method and to pass the initialization iterators to the constructor. This fixes a build problem on x86 -- reported by the auto-builder -- as a side effect. Tested-By: Guinevere Larsen <guinevere@redhat.com>
2025-01-17gdb/reverse: Fix recording vmov[u|a]p[s|d] instructionsGuinevere Larsen3-20/+29
Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were failing. In my machine xmm3 was consistently set to 0x54, but apparently that is different depending on the system. This commit zeroes out xmm3 at the start of the test instead. While debugging the test failures, I also noticed an issue where the recording wasn't saving all the required memory. That happened because vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to share code paths, but the latter encodes memory modification size on VEX.L whereas the former encodes in VEX.pp. So this commit fixed that, and made the relevant tests more robust and complete. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32561 Approved-By: Guinevere Larsen <guinevere@redhat.com>
2025-01-17Fix self-test crashTom Tromey1-1/+6
My earlier changes introduced a self-test crash. This patch fixes the bug by introducing a new method overload into mock_mapped_index.
2025-01-17gdb/doc: some more details in the README fileAndrew Burgess1-10/+33
After some recent discussions on the mailing list, I've made some changes to the README to (I hope) provide more clarity. The changes I made are: 1. Removed the use of a lone 'HOST' on the configure line. I tried this and 'configure' gave me a warning: configure: WARNING: you should use --build, --host, --target So I don't think this is approved practice any more. We should encourage users to use `--host` instead. 2. Added and reworded the --host, --target, and --enable-targets descriptions in the 'configure options' section. My goals here are to clarify that 'cross-debugging' is really the same as 'remote debugging', and also to make it clearer what the defaults are. 3. Added some additional text to the 'Remote debugging' section mentioning that 'remote debugging' is basically the same as 'cross debugging', given that we use 'cross-debugging' in the text above. Reviewed-By: Keith Seitz <keiths@redhat.com>
2025-01-17gdb: quote inferior arguments, if needed, when opening a core fileAndrew Burgess2-14/+30
This commit fixes an issue with the commit: commit d3d13bf876aae425ae0eff2ab0f1af9f7da0264a Date: Thu Apr 25 09:36:43 2024 +0100 gdb: add gdbarch method to get execution context from core file The above commit improves GDB's ability to display inferior arguments when opening a core file, however, if an argument includes white space, then this is not displayed as well as it should be. For example: (gdb) core-file /tmp/corefile-exec-context.2.core [New LWP 4069711] Reading symbols from /tmp/corefile-exec-context... Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 return ret; (gdb) show args Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e". (gdb) Notice the 'Core was generated by ...' line. In this case it is not clear if the "e e e e e" is a single argument containing white space, or 5 single arguments. But when we 'show args' it is immediately clear that this is a single argument, as the white space is now escaped. This problem was caused by the above commit building the argument string itself, and failing to consider white space escaping. This commit changes things around, first we place the arguments into the inferior, then, to print the 'Core was generated by ...' line, we ask the inferior for the argument string. In this way the quoting is handled just as it is for 'show args'. The initial output is now: (gdb) core-file /tmp/corefile-exec-context.2.core [New LWP 4069711] Reading symbols from /tmp/corefile-exec-context... Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f4f007af625 in raise () from /lib64/libc.so.6 (gdb) Much better. The existing test is extended to cover this case. Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
2025-01-17Remove mapped_index_baseTom Tromey4-875/+848
The base class mapped_index_base is no longer needed. Previously it was used by both the .gdb_index and .debug_names readers, but the latter now uses the cooked index instead. This patch removes mapped_index_base, merging it into mapped_gdb_index. Supporting code that is specific to .gdb_index is also moved into read-gdb-index.c. This shrinks dwarf2/read.c a bit, which is nice. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32504 Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-17Remove gdb_index_unpackTom Tromey1-10/+0
gdb_index_unpack is not used and can be removed. The include of extract-store-integer.h is also no longer needed by this file. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-17Add missing includes of extract-store-integer.hTom Tromey10-0/+10
I found a number of .c files that need to include extract-store-integer.h but that were only including it indirectly. This patch adds the missing includes. This change enables the next patch. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-17gdb/testsuite: Test for a backtrace through object without debuginfoGuinevere Larsen3-0/+154
Fedora has been carrying this test since back in the Project Archer days. A change back then caused GDB to stop being able to backtrace when only some of the object files had debug information. Even though the changed code never seems to have made its way into the main GDB project, I think it makes sense to bring the test along to ensure something like this doesn't pass unnoticed. Co-Authored-By: Jan Kratochvil <jan@jankratochvil.net> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-17gdb: introduce ability to disable frame unwindersGuinevere Larsen11-85/+466
Sometimes, in the GDB testsuite, we want to test the ability of specific unwinders to handle some piece of code. Usually this is done by trying to outsmart GDB, or by coercing the compiler to remove information that GDB would rely on. Both approaches have problems as GDB gets smarter with time, and that compilers might differ in version and behavior, or simply introduce new useful information. This was requested back in 2003 in PR backtrace/8434. To improve our ability to thoroughly test GDB, this patch introduces a new maintenance command that allows a user to disable some unwinders, based on either the name of the unwinder or on its class. With this change, it will now be possible for GDB to not find any frame unwinders for a given frame, which would previously cause GDB to assert. GDB will now check if any frame unwinder has been disabled, and if some has, it will just error out instead of asserting. Unwinders can be disabled or re-enabled in 3 different ways: * Disabling/enabling all at once (using '-all'). * By specifying an unwinder class to be disabled (option '-class'). * By specifying the name of an unwinder (option '-name'). If you give no options to the command, GDB assumes the input is an unwinder class. '-class' would make no difference if used, is just here for completeness. This command is meant to be used once the inferior is already at the desired location for the test. An example session would be: (gdb) start Temporary breakpoint 1, main () at omp.c:17 17 func(); (gdb) maint frame-unwinder disable ARCH (gdb) bt \#0 main () at omp.c:17 (gdb) maint frame-unwinder enable ARCH (gdb) cont Continuing. This commit is a more generic version of commit 3c3bb0580be0, and so, based on the final paragraph of the commit message: gdb: Add switch to disable DWARF stack unwinders <...> If in the future we find ourselves adding more switches to disable different unwinders, then we should probably move to a more generic solution, and remove this patch. this patch also reverts 3c3bb0580be0 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8434 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Andrew Burgess <aburgess@redhat.com> temp adding completion
2025-01-17gdb: Migrate frame unwinders to use C++ classesGuinevere Larsen87-403/+554
Frame unwinders have historically been a structure populated with callback pointers, so that architectures (or other specific unwinders) could install their own way to handle the inferior. However, since moving to C++, we could use polymorphism to get the same functionality in a more readable way. Polymorphism also makes it simpler to add new functionality to all frame unwinders, since all that's required is adding it to the base class. As part of the changes to add support to disabling frame unwinders, this commit makes the first baby step in using polymorphism for the frame unwinders, by making frame_unwind a virtual class, and adds a couple of new classes. The main class added is frame_unwind_legacy, which works the same as the previous structs, using function pointers as callbacks. This class was added to allow the transition to happen piecemeal. New unwinders should instead follow the lead of the other classes implemented. 2 of the others, frame_unwind_python and frame_unwind_trampoline, were added because it seemed simpler at the moment to do that instead of reworking the dynamic allocation to work with the legacy class, and can be used as an example to future implementations. Finally, the cygwin unwinder was converted to a class since it was most of the way there already. Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-17gdb: add "unwinder class" to frame unwindersGuinevere Larsen81-2/+168
A future patch will add a way to disable certain unwinders based on different characteristics. This patch aims to make it more convenient to disable related unwinders in bulk, such as architecture specific ones, by identifying all unwinders by which part of the code adds it. The classes, and explanations, are as follows: * GDB: An internal unwinder, added by GDB core, such as the unwinder for dummy frames; * EXTENSION: Unwinders added by extension languages; * DEBUGINFO: Unwinders installed by the debug info reader; * ARCH: Unwinders installed by the architecture specific code. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-17gdb: make gdbarch store a vector of frame unwindersGuinevere Larsen1-73/+39
Before this commit, all frame unwinders would be stored in the obstack of a gdbarch and accessed by using the registry system. This made for unwieldy code, and unnecessarily complex logic in the frame_unwinder implementation, along with making frame_unwind structs be unable to have non-trivial destructors. Seeing as a future patch of this series wants to refactor the frame_unwind struct to use inheritance, and we'd like to not restrict the future derived classes on what destructors are allowed. In preparation for that change, this commit changes the registry in gdbarch to instead store an std::vector, which doesn't require using an obstack and doesn't rely on a linked list. There should be no user-visible changes. Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-01-16[gdb/testsuite] Fix gdb.dwarf2/implptr.exp regressionTom de Vries1-1/+1
When running test-case gdb.dwarf2/implptr.exp on target board unix/-m32, we get: ... (gdb) PASS: gdb.dwarf2/implptr.exp: print ***l in implptr:bar break implptr.c:34^M No compiled code for line 34 in file "implptr.c".^M Make breakpoint pending on future shared library load? (y or [n]) n^M (gdb) FAIL: $exp: set baz breakpoint for implptr (got interactive prompt) ... This is a regression since commit dcaa85e58c4 ("gdb: reject inserting breakpoints between functions"). The .debug_line info does not contain an entry with a line number lower than 36, so gdb cannot map it to an address. Fix this by setting a breakpoint at the function containing line 34 instead. Tested on x86_64-linux. PR testsuite/32477 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32477
2025-01-16[gdb/testsuite] Fix timeouts in gdb.threads/step-over-thread-exit.expTom de Vries2-3/+11
Once in a while, I run into a timeout in test-case gdb.threads/step-over-thread-exit.exp: ... (gdb) continue^M Continuing.^M [New Thread 0xfffff7cff1a0 (LWP 2874854)]^M ^M Thread 97 "step-over-threa" hit Breakpoint 2, 0x0000000000410314 in \ my_exit_syscall () at gdb/testsuite/lib/my-syscalls.S:74^M 74 SYSCALL (my_exit, __NR_exit)^M (gdb) [Thread 0xfffff7cff1a0 (LWP 2874853) exited]^M FAIL: $exp: step_over_mode=displaced: non-stop=on: target-non-stop=on: \ schedlock=off: cmd=continue: ns_stop_all=0: iter 95: continue (timeout) ... I can reproduce it more frequently by running with taskset -c <slow core id>. Fix this by using -no-prompt-anchor. This requires us to add -no-prompt-anchor to proc gdb_test_multiple. Tested on aarch64-linux. PR testsuite/32489 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32489
2025-01-16[gdb/python] Run black on gdb/gdbarch_components.pyTom de Vries1-4/+1
The sourceware buildbot reported "python black formatter ( failure )" at commit b034bb38772 ("[gdb] Add gdbarch_dwarf2_reg_piece_offset hook"). Fix this by running the precommit hooks in a container with Python 3.11 using: ... $ pre-commit run --files gdb*/* ...
2025-01-15gdb: boolify the 'in_g_packet' field of remote's 'packet_reg'Tankut Baris Aktemur1-4/+4
Boolify the 'in_g_packet' of the 'packet_reg' struct that is used in remote.c.
2025-01-15[gdb/tdep] Fix gdb.base/store.exp on s390xTom de Vries1-0/+23
On s390x-linux, I get: ... (gdb) print l^M $29 = 0^M (gdb) FAIL: gdb.base/store.exp: var doublest l; print old l, expecting -1 ... So, we're in wack_doublest trying to print l, which is a copy of parameter u: ... register doublest l = u, r = v; ... which does have the expected value: ... (gdb) p u $1 = -1 ... which is a long double, 16 bytes and looks like this: ... (gdb) p /x u $3 = 0xbfff0000000000000000000000000000 ... Parameter u is passed in two registers: ... <2><6a5>: Abbrev Number: 15 (DW_TAG_formal_parameter) <6a6> DW_AT_name : v <69e> DW_AT_location : 6 byte block: 50 93 8 51 93 8 \ (DW_OP_reg0 (r0); DW_OP_piece: 8; DW_OP_reg1 (r1); DW_OP_piece: 8) ... and indeed we find the msw in r0 and the lsw in r1: ... (gdb) p /x $r0 $4 = 0xbfff000000000000 (gdb) p /x $r1 $5 = 0x0 (gdb) ... Likewise, variable l consists of two registers: ... <2><6b5>: Abbrev Number: 13 (DW_TAG_variable) <6b6> DW_AT_name : l <6be> DW_AT_location : 6 byte block: 68 93 8 69 93 8 \ (DW_OP_reg24 (f8); DW_OP_piece: 8; DW_OP_reg25 (f10); DW_OP_piece: 8) ... and we find the same values there: ... (gdb) p /x $f8 $6 = 0xbfff000000000000 (gdb) p /x $f10 $7 = 0x0 ... So, we get the expected results when fetching the value from two gprs, but not when fetching the value from two fprs. When fetching the values from the two fprs, we stumble upon a particularity of the DWARF register numbers as defined by the s390x ABI [1]: dwarf register 24 maps to both floating-point register f8 (8 bytes), and vector register v8 (16 bytes). In s390_dwarf_reg_to_regnum, it's determined which of the two is chosen, and if available vector registers are preferred over floating-point registers, so v8 is chosen, and used to fetch the value. Since the size of the DW_OP_piece is 8 bytes, and the register size is 16 bytes, this bit in rw_pieced_value is activated: ... /* If the piece is located in a register, but does not occupy the entire register, the placement of the piece within that register is defined by the ABI. */ bits_to_skip += 8 * gdbarch_dwarf2_reg_piece_offset (arch, gdb_regnum, p->size / 8); ... but since the default implemention default_dwarf2_reg_piece_offset does not match the s390x ABI, we get the wrong answer. This is a known problem, see FOSDEM 2018 presentation "DWARF Pieces And Other DWARF Location Woes" [2]. Fix this by adding s390_dwarf2_reg_piece_offset, roughly implementing the same logic as in s390_value_from_register. Tested on s390x-linux. Approved-By: Tom Tromey <tom@tromey.com> [1] https://github.com/IBM/s390x-abi [2] https://archive.fosdem.org/2018/schedule/event/dwarfpieces
2025-01-15[gdb] Add gdbarch_dwarf2_reg_piece_offset hookTom de Vries6-6/+91
In rw_pieced_value, when reading/writing part of a register, DW_OP_piece and DW_OP_bit_piece are handled the same, but the standard tells us: - DW_OP_piece: if the piece is located in a register, but does not occupy the entire register, the placement of the piece within that register is defined by the ABI. - DW_OP_bit_piece: if the location is a register, the offset is from the least significant bit end of the register. Add a new hook gdbarch_dwarf2_reg_piece_offset that allows us to define the ABI-specific behaviour for DW_OP_piece. The default implementation of the hook is the behaviour of DW_OP_bit_piece, so there should not be any functional changes. Tested on s390x-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-01-15[gdb/symtab] Add dwarf_expr_piece.opTom de Vries2-5/+11
Add a new field "dwarf_location_atom op" to dwarf_expr_piece to keep track of which dwarf_location_atom caused a dwarf_expr_piece to be added. This is used in the following patch. Tested on s390x-linux. Approved-By: Tom Tromey <tom@tromey.com>
2025-01-15Fix help formatting for string and filename optionsTom Tromey2-2/+8
I happened to notice that "help add-inferior" said: -execFILENAME FILENAME is the file name of the executable to use as the main program. This is missing a space after "-exec". This patch fixes the bug. If ok'd on time I plan to check this in to the gdb-16 branch as well. Approved-by: Kevin Buettner <kevinb@redhat.com>
2025-01-15gdb: LoongArch: Adjust loongarch_stopped_data_address()Hui Li3-27/+32
loongarch_stopped_data_address() is a common function and will be used by gdb and gdbserver, so move its definition from gdb/loongarch-linux-nat.c to gdb/nat/loongarch-hw-point.c. This is preparation for later gdbserver patch on LoongArch and is no effect for the current code. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2025-01-15gdb: LoongArch: Adjust loongarch_{get,remove}_debug_reg_state()Hui Li3-30/+24
loongarch_{get,remove}_debug_reg_state() are used as helper functions by loongarch_linux_nat_target. We should move their definitions from gdb/nat/loongarch-linux-hw-point.c to gdb/loongarch-linux-nat.c. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>