summaryrefslogtreecommitdiff
path: root/gdb/doc/gdb.texinfo
Commit message (Collapse)AuthorAgeFilesLines
* Add "scheduler-locking" to documentation indexTom Tromey2023-05-111-0/+1
| | | | | I noticed that "scheduler-locking" does not appear in the index of the gdb manual. This patch corrects this oversight.
* [gdb/tui] Fix tui compact-sourceTom de Vries2023-05-101-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider a hello.c, with less than 10 lines: ... $ wc -l hello.c 8 hello.c ... and compiled with -g into an a.out. With compact-source off: ... $ gdb -q a.out \ -ex "set tui border-kind ascii" \ -ex "maint set tui-left-margin-verbose on" \ -ex "set tui compact-source off" \ -ex "tui enable" ... we get: ... +-./data/hello.c-----------------------+ |___000005_{ | |___000006_ printf ("hello\n"); | |___000007_ return 0; | |___000008_} | |___000009_ | |___000010_ | |___000011_ | ... but with compact-source on: ... +-./data/hello.c-----------------------+ |___5{ | |___6 printf ("hello\n"); | |___7 return 0; | |___8} | |___9 | |___1 | |___1 | ... There are a couple of problems with compact-source. First of all the documentation mentions: ... The default display uses more space for line numbers and starts the source text at the next tab stop; the compact display uses only as much space as is needed for the line numbers in the current file, and only a single space to separate the line numbers from the source. ... The bit about the default display and the next tab stop looks incorrect. The source doesn't start at a tab stop, instead it uses a single space to separate the line numbers from the source. Then the documentation mentions that there's single space in the compact display, but evidently that's missing. Then there's the fact that the line numbers "10" and "11" are both abbreviated to "1" in the compact case. The abbreviation is due to allocating space for <lines in source>, which is 8 for this example, and takes a single digit. The line numbers though continue past the end of the file, so fix this by allocating space for max (<lines in source>, <last line in window>), which in this example takes 2 digits. The missing space is due to some confusion about what the "1" here in tui_source_window::set_contents represent: ... double l = log10 ((double) offsets->size ()); m_digits = 1 + (int) l; ... It could be the trailing space that's mentioned in tui-source.h: ... /* How many digits to use when formatting the line number. This includes the trailing space. */ int m_digits; ... Then again, it could be part of the calculation for the number of digits needed for printing. With this minimal example: ... int main () { for (int i = 8; i <= 11; ++i) { double l = log10 ((double) i); printf ("%d %d\n", i, (int)l); } return 0; } ... we get: ... $ ./a.out 8 0 9 0 10 1 11 1 ... which shows that the number of digits needed for printing i is "1 + (int)log10 ((double) i)". Fix this by introducing named variables needed_digits and trailing_space, each adding 1. With the fixes, we get for compact-source on: ... +-./data/hello.c-----------------------+ |___05_{ | |___06_ printf ("hello\n"); | |___07_ return 0; | |___08_} | |___09_ | |___10_ | |___11_ | |... Also fix the documentation and help text to actually match effect of compact-source. Tested on x86_64-linux.
* Don't treat references to compound values as "simple".Gareth Rees2023-05-041-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SUMMARY The '--simple-values' argument to '-stack-list-arguments' and similar GDB/MI commands does not take reference types into account, so that references to arbitrarily large structures are considered "simple" and printed. This means that the '--simple-values' argument cannot be used by IDEs when tracing the stack due to the time taken to print large structures passed by reference. DETAILS Various GDB/MI commands ('-stack-list-arguments', '-stack-list-locals', '-stack-list-variables' and so on) take a PRINT-VALUES argument which may be '--no-values' (0), '--all-values' (1) or '--simple-values' (2). In the '--simple-values' case, the command is supposed to print the name, type, and value of variables with simple types, and print only the name and type of variables with compound types. The '--simple-values' argument ought to be suitable for IDEs that need to update their user interface with the program's call stack every time the program stops. However, it does not take C++ reference types into account, and this makes the argument unsuitable for this purpose. For example, consider the following C++ program: struct s { int v[10]; }; int sum(const struct s &s) { int total = 0; for (int i = 0; i < 10; ++i) total += s.v[i]; return total; } int main(void) { struct s s = { { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } }; return sum(s); } If we start GDB in MI mode and continue to 'sum', the behaviour of '-stack-list-arguments' is as follows: (gdb) -stack-list-arguments --simple-values ^done,stack-args=[frame={level="0",args=[{name="s",type="const s &",value="@0x7fffffffe310: {v = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}}"}]},frame={level="1",args=[]}] Note that the value of the argument 's' was printed, even though 's' is a reference to a structure, which is not a simple value. See https://github.com/microsoft/MIEngine/pull/673 for a case where this behaviour caused Microsoft to avoid the use of '--simple-values' in their MIEngine debug adapter, because it caused Visual Studio Code to take too long to refresh the call stack in the user interface. SOLUTIONS There are two ways we could fix this problem, depending on whether we consider the current behaviour to be a bug. 1. If the current behaviour is a bug, then we can update the behaviour of '--simple-values' so that it takes reference types into account: that is, a value is simple if it is neither an array, struct, or union, nor a reference to an array, struct or union. In this case we must add a feature to the '-list-features' command so that IDEs can detect that it is safe to use the '--simple-values' argument when refreshing the call stack. 2. If the current behaviour is not a bug, then we can add a new option for the PRINT-VALUES argument, for example, '--scalar-values' (3), that would be suitable for use by IDEs. In this case we must add a feature to the '-list-features' command so that IDEs can detect that the '--scalar-values' argument is available for use when refreshing the call stack. PATCH This patch implements solution (1) as I think the current behaviour of not printing structures, but printing references to structures, is contrary to reasonable expectation. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29554
* Document DAP 'launch' parameterTom Tromey2023-05-011-0/+19
| | | | | | | | | | | | | | The Debugger Adapter Protocol defines a "launch" request but leaves the parameters up to the implementation: Since launching is debugger/runtime specific, the arguments for this request are not part of this specification. This patch adds some documentation for the parameter GDB currently defines. Note that I plan to add more parameters here, and perhaps there will be other extensions in time as well. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
* gdb/mi: check thread exists when creating thread-specific b/pAndrew Burgess2023-04-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed the following behaviour: $ gdb -q -i=mi /tmp/hello.x =thread-group-added,id="i1" =cmd-param-changed,param="print pretty",value="on" ~"Reading symbols from /tmp/hello.x...\n" (gdb) -break-insert -p 99 main ^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401198",func="main",file="/tmp/hello.c",fullname="/tmp/hello.c",line="18",thread-groups=["i1"],thread="99",times="0",original-location="main"} (gdb) info breakpoints &"info breakpoints\n" ~"Num Type Disp Enb Address What\n" ~"1 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18\n" &"../../src/gdb/thread.c:1434: internal-error: print_thread_id: Assertion `thr != nullptr' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable." &"\n" &"----- Backtrace -----\n" &"Backtrace unavailable\n" &"---------------------\n" &"\nThis is a bug, please report it." &" For instructions, see:\n" &"<https://www.gnu.org/software/gdb/bugs/>.\n\n" Aborted (core dumped) What we see here is that when using the MI a user can create thread-specific breakpoints for non-existent threads. Then if we try to use the CLI 'info breakpoints' command GDB throws an assertion. The assert is a result of the print_thread_id call when trying to build the 'stop only in thread xx.yy' line; print_thread_id requires a valid thread_info pointer, which we can't have for a non-existent thread. In contrast, when using the CLI we see this behaviour: $ gdb -q /tmp/hello.x Reading symbols from /tmp/hello.x... (gdb) break main thread 99 Unknown thread 99. (gdb) The CLI doesn't allow a breakpoint to be created for a non-existent thread. So the 'info breakpoints' command is always fine. Interestingly, the MI -break-info command doesn't crash, this is because the MI uses global thread-ids, and so never calls print_thread_id. However, GDB does support using CLI and MI in parallel, so we need to solve this problem. One option would be to change the CLI behaviour to allow printing breakpoints for non-existent threads. This would preserve the current MI behaviour. The other option is to pull the MI into line with the CLI and prevent breakpoints being created for non-existent threads. This is good for consistency, but is a breaking change for the MI. In the end I figured that it was probably better to retain the consistent CLI behaviour, and just made the MI reject requests to place a breakpoint on a non-existent thread. The only test we had that depended on the old behaviour was gdb.mi/mi-thread-specific-bp.exp, which was added by me in commit: commit 2fd9a436c8d24eb0af85ccb3a2fbdf9a9c679a6c Date: Fri Feb 17 10:48:06 2023 +0000 gdb: don't duplicate 'thread' field in MI breakpoint output I certainly didn't intend for this test to rely on this feature of the MI, so I propose to update this test to only create breakpoints for threads that exist. Actually, I've added a new test that checks the MI rejects creating a breakpoint for a non-existent thread, and I've also extended the test to run with the separate MI/CLI UIs, and then tested 'info breakpoints' to ensure this command doesn't crash. I've extended the documentation of the `-p` flag to explain the constraints better. I have also added a NEWS entry just in case someone runs into this issue, at least then they'll know this change in behaviour was intentional. One thing that I did wonder about while writing this patch, is whether we should treat requests like this, on both the MI and CLI, as another form of pending breakpoint, something like: (gdb) break foo thread 9 Thread 9 does not exist. Make breakpoint pending on future thread creation? (y or [n]) y Breakpoint 1 (foo thread 9) pending. (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y <PENDING> foo thread 9 Don't know if folk think that would be a useful idea or not? Either way, I think that would be a separate patch from this one. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
* Fix a typo in gdb.texinfo.Eli Zaretskii2023-04-281-1/+1
|
* gdb/doc: extend the documentation of the jump commandAndrew Burgess2023-04-271-0/+8
| | | | | | | | | | | | | | | | | | This commit addresses PR gdb/7946. While checking for bugs relating to the jump command I noticed a long standing bug that points out a deficiency with GDB's documentation of the jump command. The bug points out that 'jump 0x...' is not always the same as 'set $pc = 0x...' and then 'continue'. Writing directly to the $pc register does not update any auxiliary state, e.g. $npc on SPARC, while using 'jump' does. It felt like this would be an easy issue to address by adding a paragraph to the docs, so I took a stab at writing something suitable. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7946 Approved-By: Eli Zaretskii <eliz@gnu.org>
* gdb, doc: add index entry for the $_inferior_thread_count convenience varTankut Baris Aktemur2023-04-271-0/+1
| | | | | | | Add a marker in the documentation for indexing the $_inferior_thread_count variable. Approved-By: Eli Zaretskii <eliz@gnu.org>
* [gdb/cli] Add maint info screenTom de Vries2023-04-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While working on PRs tui/30337 and cli/30346 I came across various notions of width in gdb, as reported by gdb, readline, curses and the environment variables. As for gdb, readline and the environment variables, the way things work is: - Gdb asks readline to detect screen size, - readline sets the actual screen size in the environment variables COLUMNS and LINES, - readline reports back a screen size to gdb, which may have one column less than the actual screen size, to deal with lack of auto-wrap. This becomes gdb's notion of screen size (in other words the point where we can expect the gdb command line to wrap), - Gdb then explicitly sets readline's screen size, which readline itself may adjust to deal with lack of auto-wrap. This becomes readlines notion of screen size (well, internally the unadjusted one, but it'll report back the adjusted one). Add a command "maint info screen" that prints these notions, both for width and height. For TERM=xterm we have: ... $ TERM=xterm gdb -ex "maint info screen" Number of characters gdb thinks are in a line is 118. Number of characters readline reports are in a line is 118. Number of characters curses thinks are in a line is 118. Number of characters environment thinks are in a line is 118 (COLUMNS). Number of lines gdb thinks are in a page is 27. Number of lines readline reports are in a page is 27. Number of lines curses thinks are in a page is 27. Number of lines environment thinks are in a page is 27 (LINES). ... And for TERM=ansi: ... $ TERM=ansi gdb -ex "maint info screen" Number of characters gdb thinks are in a line is 117. Number of characters readline reports are in a line is 116. Number of characters curses thinks are in a line is 118. Number of characters environment thinks are in a line is 118 (COLUMNS). Number of lines gdb thinks are in a page is 27. Number of lines readline reports are in a page is 27. Number of lines curses thinks are in a page is 27. Number of lines environment thinks are in a page is 27 (LINES). ... [ The fact that we have "characters readline reports are in a line is 116" is is due to gdb making readline adjust twice for the lack of auto-wrap, this is PR cli/30346. Likewise we can detect tui/30337 by doing a resize in TUI mode and doing "maint info screen": ... Number of characters characters curses thinks are in a line is 110. Number of characters environment thinks are in a line is 111 (COLUMNS). ] And for TERM=ansi, with width and heigth set to 0: ... Number of characters gdb thinks are in a line is 4294967295 (unlimited). Number of characters readline reports are in a line is 32766 (unlimited - 1). Number of characters curses thinks are in a line is 118. Number of characters environment thinks are in a line is 118 (COLUMNS). Number of lines gdb thinks are in a page is 4294967295 (unlimited). Number of lines readline reports are in a page is 32767 (unlimited). Number of lines curses thinks are in a page is 27. Number of lines environment thinks are in a page is 27 (LINES). ... [ Note that when doing a resize by say maximizing or de-maximizing a terminal, all reported values are updated, except for curses when not in TUI mode. Maybe that means there's a bug. If not, then maybe we should not print the curses lines unless in TUI mode, or annotate those lines such that it's clear that the values may be not up-to-date. ] I'd like to use this command in the regression test for PR cli/30346. Tested on x86_64-linux. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Tom Tromey <tom@tromey.com>
* pauth: Create new feature string for pauth to prevent crashing older gdb'sLuis Machado2023-04-141-0/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Older gdb's (9, 10, 11 and 12) have a bug that causes them to crash whenever a target reports the pauth feature string in the target description and also provide additional register outside of gdb's known and expected feature strings. This was fixed in gdb 13 onwards, but that means we're stuck with gdb's out there that will crash on connection to the above targets. QEMU has postponed inclusion of the pauth feature string in version 8, and instead we agreed to use a new feature name to prevent crashing those older gdb's. Initially there was a plan to backport a trivial fix all the way to gdb 9, but given QEMU's choice, this is no longer needed. This new feature string is org.gnu.gdb.aarch64.pauth_v2, and should be used by all targets going forward, except native linux gdb and gdbserver, for backwards compatibility with older gdb's/gdbserver's. gdb/gdbserver will still emit the old feature string for Linux since it doesn't report additional system registers and thus doesn't cause a crash of older gdb's. We can revisit this in the future once the problematic gdb's are likely no longer in use. I've added some documentation to explain the situation.
* [gdb/tui] Add maint set/show tui-left-margin-verboseTom de Vries2023-04-131-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TUI has two types of windows derived from tui_source_window_base: - tui_source_window (the source window), and - tui_disasm_window (the disassembly window). The two windows share a common concept: the left margin. With a hello world a.out, we can see the source window: ... ┌─/home/vries/hello.c───────────────────────────────────────┐ │ 5 { │ │B+> 6 printf ("hello\n"); │ │ 7 return 0; │ │ 8 } │ │ 9 │ │ ... where the left margin is the part holding "B+>" and the line number, and the disassembly window: ... ┌───────────────────────────────────────────────────────────┐ │ 0x555555555149 <main> endbr64 │ │ 0x55555555514d <main+4> push %rbp │ │ 0x55555555514e <main+5> mov %rsp,%rbp │ │B+> 0x555555555151 <main+8> lea 0xeac(%rip),%rax│ │ 0x555555555158 <main+15> mov %rax,%rdi │ ... where the left margin is just the bit holding "B+>". Because the left margin contains some spaces, it's not clear where it starts and ends, making it harder to observe problems related to it. Add a new maintenance command "maint set tui-left-margin-verbose", that when set to on replaces the spaces in the left margin with either '_' or '0', giving us this for the source window: ... ┌─/home/vries/hello.c───────────────────────────────────────┐ │___000005__{ │ │B+>000006__ printf ("hello\n"); │ │___000007__ return 0; │ │___000008__} │ ... and this for the disassembly window: ... ┌───────────────────────────────────────────────────────────┐ │___ 0x555555555149 <main> endbr64 │ │___ 0x55555555514d <main+4> push %rbp │ │___ 0x55555555514e <main+5> mov %rsp,%rbp │ │B+> 0x555555555151 <main+8> lea 0xeac(%rip),%rax│ │___ 0x555555555158 <main+15> mov %rax,%rdi │ ... Note the space between "B+>" and 0x555555555151. The space shows that a bit of the left margin is not written, a problem reported as PR tui/30325. Specifically, PR tui/30325 is about the fact that the '[' character from the string "[ No Assembly Available ]" ends up in that same spot: ... │B+>[0x555555555151 <main+8> lea 0xeac(%rip),%rax│ ... which only happens for certain window widths. The new command allows us to spot the problem with any window width. Likewise, when we revert the fix from commit 1b6d4bb2232 ("Redraw both spaces between line numbers and source code"), we have: ... ┌─/home/vries/hello.c───────────────────────────────────────┐ │___000005_ { │ │B+>000006_ printf ("hello\n"); │ │___000007_ return 0; │ │___000008_ } │ ... showing a similar problem at the space between '_' and '{'. Tested on x86_64-linux. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
* gdb, doc: correct argument description for info connections/inferiorsNils-Christian Kempke2023-04-111-6/+13
| | | | | | | | | | | It said for 'info inferiors' and 'info connections' that the argument could be 'a space separated list of inferior numbers' which is correct but incomplete. In fact the arguments can be any space separated combination of numbers and (ascending) ranges. The beginning of the section now describes the ID list as a new keyword. Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
* Fix typos in previous commit of gdb.texinfo.Philippe Blain2023-04-081-4/+5
| | | | * gdb/doc/gdb.texinfo (Requirements): Fix typos.
* Improve documentation of GDB build requirements and optionsEli Zaretskii2023-04-051-100/+103
| | | | | | | | | | | | | | | | | MPFR is now mandatory, so its previous description in Requirements was inappropriate and out of place. In addition, the description of how to go about specifying 'configure' time options for building with libraries was highly repetitive. Some of the text was also outdated and used wrong markup. Original patch and suggestions from Philippe Blain <levraiphilippeblain@gmail.com>. ChangeLog: 2023-04-05 Eli Zaretskii <eliz@gnu.org> * gdb/doc/gdb.texinfo (Requirements, Configure Options): Update and rearrange; improve and fix markup.
* gdb, doc: add the missing '-gid' option to 'info threads'Tankut Baris Aktemur2023-04-051-1/+1
| | | | | | | | The 'info threads' command does not show the '-gid' option in the syntax. Add the option. The flag is already explained in the command description and used in the examples. Approved-By: Eli Zaretskii <eliz@gnu.org>
* GDB: Add `info main' commandRichard Bunt2023-03-311-0/+6
| | | | | | | | | | Allow consumers of GDB to extract the name of the main method. This is most useful for Fortran programs which have a variable main method. Used by both MAP and DDT e.g. it is used to detect the presence of debug information. Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
* doc: fix informations typo in gdb.texinfoNils-Christian Kempke2023-03-291-2/+2
| | | | Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
* Put pretty-printers to_string output in varobj resultTom Tromey2023-03-281-2/+3
| | | | | | | | | | | | | | | PR mi/11335 points out that an MI varobj will not display the result of a pretty-printer's "to_string" method. Instead, it always shows "{...}". This does not seem very useful, and there have been multiple complaints about it over the years. This patch changes varobj to emit this string when possible, and updates the test suite. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11335
* gdb/doc: extended documentation for inferior function callsAndrew Burgess2023-03-161-0/+32
| | | | | | | | | | I noticed that the documentation for inferior function calls doesn't say much about what happens if/when an inferior function call is interrupted, i.e. it doesn't describe what the dummy frame looks like on the stack, or how GDB behaves when the inferior is continued and reaches the dummy frame. This commit aims to add some of this missing information.
* aarch64: Expand documentation of XML featuresLuis Machado2023-03-131-8/+202
| | | | | | | | | | Similar to the arm target documentation situation, the documentation of the XML features for AArch64 targets is rather brief. I have received the same feedback that what gdb carries in the documentation is quite unclear from the perspective of what debugging servers should define in the XML features, how and what the outcome is in gdb. This patch attempts to clarify a bit more what all the possible features are.
* arm: Expand documentation of XML featuresLuis Machado2023-03-131-24/+259
| | | | | | | | | The documentation of the XML features for Arm targets is very brief. I have received feedback saying it is quite unclear from the perspective of the debugging servers what should be defined in the XML features, how and what the outcome is in gdb. This patch attempts to clarify a bit more what all the possible features are.
* Ensure index cache entry written in testTom Tromey2023-03-071-0/+6
| | | | | | | | | | | | Now that index cache files are written in the background, one test in index-cache.exp is racy -- it assumes that the cache file will have been written during startup. This patch fixes the problem by introducing a new maintenance command to wait for all pending writes to the index cache. Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
* [gdb/symtab] Add set/show always-read-ctf on/offTom de Vries2023-03-021-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ This is a simplified rewrite of an earlier submission "[RFC][gdb/symtab] Add maint set symbol-read-order", submitted here ( https://sourceware.org/pipermail/gdb-patches/2022-September/192044.html ). ] With the test-case included in this patch, we run into: ... (gdb) file dwarf2-and-ctf (gdb) print var_ctf^M 'var_ctf' has unknown type; cast it to its declared type^M ... The problem is that the executable contains both ctf and dwarf2, so the ctf info (which contains the type information about var_ctf) is ignored. GDB has support for handling multiple debug formats, but the common use case for ctf is to be used when dwarf2 is not present, and gdb reflects that, assuming that by reading ctf in addition there won't be any extra information, so it's not worth the additional cycles and memory. Add a new command "set/show always-read-ctf on/off", that when on forces unconditional reading of ctf, allowing us to do: ... (gdb) set always-read-ctf on (gdb) file dwarf2-and-ctf (gdb) print var_ctf^M $2 = 2^M ... The setting is off by default, preserving current behaviour. A bit of background on the relevance of reading order: the formats have a priority relationship between them, where reading earlier means lower priority. By reading the format with the most detail last, we ensure it has the highest priority, which makes sure that in case there is overlapping info, the most detailed info is found. This explains the current reading order of mdebug, stabs and dwarf2. Add the unconditional reading of ctf before dwarf2, because it's less detailed than dwarf2. The conditional reading of ctf is still done after the attempt to read dwarf2, necessarily so because we only know whether there's dwarf2 after we've tried to read it. The new command allow us to replace uses of -Wl,--strip-debug added in commit 908a926ec4e ("[gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed") by uses of "set always-read-ctf on", but I've left that for another commit. Tested on x86_64-linux. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Tom Tromey <tom@tromey.com>
* gdb/doc: The RISC-V vector registers didn't changePalmer Dabbelt2023-02-231-5/+1
| | | | | | | When we merged the GDB vector register support we did it a bit early, just eating the risk in the very unlikely case that the vector register names changed. They didn't, so we can now remove the caveat in the docs that they might.
* gdb/doc: Consistency fixes for GDB/MI documentationAndrew Burgess2023-02-201-27/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed two inconsistencies in the GDB/MI documentation, which this commit addresses: 1. Each MI command is introduced like this: @subheading The @code{-command-name} Command Except for a few of the tracing command, which just use: @subheading -command-name In this commit I've updated all these trace commands to use the more common format. 2. Each MI command starts with a @subheading, and then the details of that command are split up using multiple @subsubheading entries. Except for a few commands which use @subheading for the top-level command, and then continue to use @subheading for each part of the command description. In this commit I've updated these to use @subsubheading where appropriate.
* Update the 'g' packet documentationTom Tromey2023-02-161-10/+20
| | | | | | | | | | | The 'g' packet documentation references a macro that no longer exists, and it also claims that the 'x' response for an unavailable register is limited to trace frames. This patch updates the documentation to reflect what I think is currently correct. Co-Authored-By: Pedro Alves <pedro@palves.net> Approved-By: Eli Zaretskii <eliz@gnu.org> Change-Id: I863baa3b9293059cfd4aa3d534602cbcb693ba87
* gdb/doc: document MI -remove-inferior commandAndrew Burgess2023-02-161-0/+34
| | | | | | | | | | Back in 2010 the -remove-inferior command was added in commit a79b8f6ea8c2, unfortunately this command was never added to the documentation. This commit addresses that oversight. Approved-By: Eli Zaretskii <eliz@gnu.org>
* Add new "$_shell(CMD)" internal functionPedro Alves2023-02-151-1/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For testing a following patch, I wanted a way to send a SIGINT to GDB from a breakpoint condition. And I didn't want to do it from a Python breakpoint or Python function, as I wanted to exercise non-Python code paths. So I thought I'd add a new $_shell internal function, that runs a command under the shell, and returns the exit code. With this, I could write: (gdb) b foo if $_shell("kill -SIGINT $gdb_pid") != 0 || <other condition> I think this is generally useful, hence I'm proposing it here. Here's the new function in action: (gdb) p $_shell("true") $1 = 0 (gdb) p $_shell("false") $2 = 1 (gdb) p $_shell("echo hello") hello $3 = 0 (gdb) p $_shell("foobar") bash: line 1: foobar: command not found $4 = 127 (gdb) help function _shell $_shell - execute a shell command and returns the result. Usage: $_shell (command) Returns the command's exit code: zero on success, non-zero otherwise. (gdb) NEWS and manual changes included. Approved-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Eli Zaretskii <eliz@gnu.org> Change-Id: I7e36d451ee6b428cbf41fded415ae2d6b4efaa4e
* gdb/manual: Move @findex entriesPedro Alves2023-02-151-165/+165
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The manual currently has many cases like these: @item $_gdb_setting_str (@var{setting}) @findex $_gdb_setting_str@r{, convenience function} As suggested by Eli, move the @findex entries before @item so that the index records the position of @item, and the Info reader places you there when you use index-search. I went over all @findex calls in the manual, and most are like the above. Most either appear before @item, or before @subheading, like: @subheading The @code{-break-after} Command @findex -break-after I fixed all of them. There are findex entries in annotate.texinfo,python.texi, and stabs.texinfo as well, though those all look right to me already. Tested by typing "i _isvoid" (@item case) and "i -complete" (@subheading case) in an Info reader, and checking where those took me. Change-Id: Idb6903b0bb39ff03f93524628dcef86b5585c97e Suggested-By: Eli Zaretskii <eliz@gnu.org>
* GDB: Introduce limited array lengths while printing valuesAndrew Burgess2023-02-101-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces the idea of loading only part of an array in order to print it, what I call "limited length" arrays. The motivation behind this work is to make it possible to print slices of very large arrays, where very large means bigger than `max-value-size'. Consider this GDB session with the current GDB: (gdb) set max-value-size 100 (gdb) p large_1d_array value requires 400 bytes, which is more than max-value-size (gdb) p -elements 10 -- large_1d_array value requires 400 bytes, which is more than max-value-size notice that the request to print 10 elements still fails, even though 10 elements should be less than the max-value-size. With a patched version of GDB: (gdb) p -elements 10 -- large_1d_array $1 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...} So now the print has succeeded. It also has loaded `max-value-size' worth of data into value history, so the recorded value can be accessed consistently: (gdb) p -elements 10 -- $1 $2 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9...} (gdb) p $1 $3 = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, <unavailable> <repeats 75 times>} (gdb) Accesses with other languages work similarly, although for Ada only C-style [] array element/dimension accesses use history. For both Ada and Fortran () array element/dimension accesses go straight to the inferior, bypassing the value history just as with C pointers. Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
* [gdb/cli] Add maint info frame-unwindersTom de Vries2023-02-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new command "maint info frame-unwinders": ... (gdb) help maint info frame-unwinders List the frame unwinders currently in effect, starting with the highest \ priority. ... Output for i386: ... $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders" The target architecture is set to "i386". dummy DUMMY_FRAME dwarf2 tailcall TAILCALL_FRAME inline INLINE_FRAME i386 epilogue NORMAL_FRAME dwarf2 NORMAL_FRAME dwarf2 signal SIGTRAMP_FRAME i386 stack tramp NORMAL_FRAME i386 sigtramp SIGTRAMP_FRAME i386 prologue NORMAL_FRAME ... Output for x86_64: ... $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders" The target architecture is set to "i386:x86-64". dummy DUMMY_FRAME dwarf2 tailcall TAILCALL_FRAME inline INLINE_FRAME python NORMAL_FRAME amd64 epilogue NORMAL_FRAME i386 epilogue NORMAL_FRAME dwarf2 NORMAL_FRAME dwarf2 signal SIGTRAMP_FRAME amd64 sigtramp SIGTRAMP_FRAME amd64 prologue NORMAL_FRAME i386 stack tramp NORMAL_FRAME i386 sigtramp SIGTRAMP_FRAME i386 prologue NORMAL_FRAME ... Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
* gdb/doc: extend the documentation for the 'handle' commandAndrew Burgess2023-02-061-7/+8
| | | | | | | | | | | | | | | The documentation for the 'handle' command does not cover all of the features of the command, and in one case, is just wrong. The user can specify 'all' as signal name, the documentation implies that this will change the behaviour of all signals, in reality, this changes all signals except SIGINT and SIGTRAP (the signals used by GDB). I've updated the docs to list this limitation. The 'handle' command also allows the user to specify multiple signals for a single command, e.g. 'handle SIGFPE SIGILL nostop pass print', however the documentation doesn't describe this, so I've updated the docs to describe this feature.
* gdb: initial support for ROCm platform (AMDGPU) debuggingSimon Marchi2023-02-021-0/+291
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the foundation for GDB to be able to debug programs offloaded to AMD GPUs using the AMD ROCm platform [1]. The latest public release of the ROCm release at the time of writing is 5.4, so this is what this patch targets. The ROCm platform allows host programs to schedule bits of code for execution on GPUs or similar accelerators. The programs running on GPUs are typically referred to as `kernels` (not related to operating system kernels). Programs offloaded with the AMD ROCm platform can be written in the HIP language [2], OpenCL and OpenMP, but we're going to focus on HIP here. The HIP language consists of a C++ Runtime API and kernel language. Here's an example of a very simple HIP program: #include "hip/hip_runtime.h" #include <cassert> __global__ void do_an_addition (int a, int b, int *out) { *out = a + b; } int main () { int *result_ptr, result; /* Allocate memory for the device to write the result to. */ hipError_t error = hipMalloc (&result_ptr, sizeof (int)); assert (error == hipSuccess); /* Run `do_an_addition` on one workgroup containing one work item. */ do_an_addition<<<dim3(1), dim3(1), 0, 0>>> (1, 2, result_ptr); /* Copy result from device to host. Note that this acts as a synchronization point, waiting for the kernel dispatch to complete. */ error = hipMemcpyDtoH (&result, result_ptr, sizeof (int)); assert (error == hipSuccess); printf ("result is %d\n", result); assert (result == 3); return 0; } This program can be compiled with: $ hipcc simple.cpp -g -O0 -o simple ... where `hipcc` is the HIP compiler, shipped with ROCm releases. This generates an ELF binary for the host architecture, containing another ELF binary with the device code. The ELF for the device can be inspected with: $ roc-obj-ls simple 1 host-x86_64-unknown-linux file://simple#offset=8192&size=0 1 hipv4-amdgcn-amd-amdhsa--gfx906 file://simple#offset=8192&size=34216 $ roc-obj-extract 'file://simple#offset=8192&size=34216' $ file simple-offset8192-size34216.co simple-offset8192-size34216.co: ELF 64-bit LSB shared object, *unknown arch 0xe0* version 1, dynamically linked, with debug_info, not stripped ^ amcgcn architecture that my `file` doesn't know about ----´ Running the program gives the very unimpressive result: $ ./simple result is 3 While running, this host program has copied the device program into the GPU's memory and spawned an execution thread on it. The goal of this GDB port is to let the user debug host threads and these GPU threads simultaneously. Here's a sample session using a GDB with this patch applied: $ ./gdb -q -nx --data-directory=data-directory ./simple Reading symbols from ./simple... (gdb) break do_an_addition Function "do_an_addition" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (do_an_addition) pending. (gdb) r Starting program: /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff5db7640 (LWP 1082911)] [New Thread 0x7ffef53ff640 (LWP 1082913)] [Thread 0x7ffef53ff640 (LWP 1082913) exited] [New Thread 0x7ffdecb53640 (LWP 1083185)] [New Thread 0x7ffff54bf640 (LWP 1083186)] [Thread 0x7ffdecb53640 (LWP 1083185) exited] [Switching to AMDGPU Wave 2:2:1:1 (0,0,0)/0] Thread 6 hit Breakpoint 1, do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24 24 *out = a + b; (gdb) info inferiors Num Description Connection Executable * 1 process 1082907 1 (native) /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple (gdb) info threads Id Target Id Frame 1 Thread 0x7ffff5dc9240 (LWP 1082907) "simple" 0x00007ffff5e9410b in ?? () from /opt/rocm-5.4.0/lib/libhsa-runtime64.so.1 2 Thread 0x7ffff5db7640 (LWP 1082911) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36 5 Thread 0x7ffff54bf640 (LWP 1083186) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36 * 6 AMDGPU Wave 2:2:1:1 (0,0,0)/0 do_an_addition ( a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24 (gdb) bt Python Exception <class 'gdb.error'>: Unhandled dwarf expression opcode 0xe1 #0 do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>, out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24 (gdb) continue Continuing. result is 3 warning: Temporarily disabling breakpoints for unloaded shared library "file:///home/smarchi/build/binutils-gdb-amdgpu/gdb/simple#offset=8192&size=67208" [Thread 0x7ffff54bf640 (LWP 1083186) exited] [Thread 0x7ffff5db7640 (LWP 1082911) exited] [Inferior 1 (process 1082907) exited normally] One thing to notice is the host and GPU threads appearing under the same inferior. This is a design goal for us, as programmers tend to think of the threads running on the GPU as part of the same program as the host threads, so showing them in the same inferior in GDB seems natural. Also, the host and GPU threads share a global memory space, which fits the inferior model. Another thing to notice is the error messages when trying to read variables or printing a backtrace. This is expected for the moment, since the AMD GPU compiler produces some DWARF that uses some non-standard extensions: https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html There were already some patches posted by Zoran Zaric earlier to make GDB support these extensions: https://inbox.sourceware.org/gdb-patches/20211105113849.118800-1-zoran.zaric@amd.com/ We think it's better to get the basic support for AMD GPU in first, which will then give a better justification for GDB to support these extensions. GPU threads are named `AMDGPU Wave`: a wave is essentially a hardware thread using the SIMT (single-instruction, multiple-threads) [3] execution model. GDB uses the amd-dbgapi library [4], included in the ROCm platform, for a few things related to AMD GPU threads debugging. Different components talk to the library, as show on the following diagram: +---------------------------+ +-------------+ +------------------+ | GDB | amd-dbgapi target | <-> | AMD | | Linux kernel | | +-------------------+ | Debugger | +--------+ | | | amdgcn gdbarch | <-> | API | <=> | AMDGPU | | | +-------------------+ | | | driver | | | | solib-rocm | <-> | (dbgapi.so) | +--------+---------+ +---------------------------+ +-------------+ - The amd-dbgapi target is a target_ops implementation used to control execution of GPU threads. While the debugging of host threads works by using the ptrace / wait Linux kernel interface (as usual), control of GPU threads is done through a special interface (dubbed `kfd`) exposed by the `amdgpu` Linux kernel module. GDB doesn't interact directly with `kfd`, but instead goes through the amd-dbgapi library (AMD Debugger API on the diagram). Since it provides execution control, the amd-dbgapi target should normally be a process_stratum_target, not just a target_ops. More on that later. - The amdgcn gdbarch (describing the hardware architecture of the GPU execution units) offloads some requests to the amd-dbgapi library, so that knowledge about the various architectures doesn't need to be duplicated and baked in GDB. This is for example for things like the list of registers. - The solib-rocm component is an solib provider that fetches the list of code objects loaded on the device from the amd-dbgapi library, and makes GDB read their symbols. This is very similar to other solib providers that handle shared libraries, except that here the shared libraries are the pieces of code loaded on the device. Given that Linux host threads are managed by the linux-nat target, and the GPU threads are managed by the amd-dbgapi target, having all threads appear in the same inferior requires the two targets to be in that inferior's target stack. However, there can only be one process_stratum_target in a given target stack, since there can be only one target per slot. To achieve it, we therefore resort the hack^W solution of placing the amd-dbgapi target in the arch_stratum slot of the target stack, on top of the linux-nat target. Doing so allows the amd-dbgapi target to intercept target calls and handle them if they concern GPU threads, and offload to beneath otherwise. See amd_dbgapi_target::fetch_registers for a simple example: void amd_dbgapi_target::fetch_registers (struct regcache *regcache, int regno) { if (!ptid_is_gpu (regcache->ptid ())) { beneath ()->fetch_registers (regcache, regno); return; } // handle it } ptids of GPU threads are crafted with the following pattern: (pid, 1, wave id) Where pid is the inferior's pid and "wave id" is the wave handle handed to us by the amd-dbgapi library (in practice, a monotonically incrementing integer). The idea is that on Linux systems, the combination (pid != 1, lwp == 1) is not possible. lwp == 1 would always belong to the init process, which would also have pid == 1 (and it's improbable for the init process to offload work to the GPU and much less for the user to debug it). We can therefore differentiate GPU and non-GPU ptids this way. See ptid_is_gpu for more details. Note that we believe that this scheme could break down in the context of containers, where the initial process executed in a container has pid 1 (in its own pid namespace). For instance, if you were to execute a ROCm program in a container, then spawn a GDB in that container and attach to the process, it will likely not work. This is a known limitation. A workaround for this is to have a dummy process (like a shell) fork and execute the program of interest. The amd-dbgapi target watches native inferiors, and "attaches" to them using amd_dbgapi_process_attach, which gives it a notifier fd that is registered in the event loop (see enable_amd_dbgapi). Note that this isn't the same "attach" as in PTRACE_ATTACH, but being ptrace-attached is a precondition for amd_dbgapi_process_attach to work. When the debugged process enables the ROCm runtime, the amd-dbgapi target gets notified through that fd, and pushes itself on the target stack of the inferior. The amd-dbgapi target is then able to intercept target_ops calls. If the debugged process disables the ROCm runtime, the amd-dbgapi target unpushes itself from the target stack. This way, the amd-dbgapi target's footprint stays minimal when debugging a process that doesn't use the AMD ROCm platform, it does not intercept target calls. The amd-dbgapi library is found using pkg-config. Since enabling support for the amdgpu architecture (amdgpu-tdep.c) depends on the amd-dbgapi library being present, we have the following logic for the interaction with --target and --enable-targets: - if the user explicitly asks for amdgcn support with --target=amdgcn-*-* or --enable-targets=amdgcn-*-*, we probe for the amd-dbgapi and fail if not found - if the user uses --enable-targets=all, we probe for amd-dbgapi, enable amdgcn support if found, disable amdgcn support if not found - if the user uses --enable-targets=all and --with-amd-dbgapi=yes, we probe for amd-dbgapi, enable amdgcn if found and fail if not found - if the user uses --enable-targets=all and --with-amd-dbgapi=no, we do not probe for amd-dbgapi, disable amdgcn support - otherwise, amd-dbgapi is not probed for and support for amdgcn is not enabled Finally, a simple test is included. It only tests hitting a breakpoint in device code and resuming execution, pretty much like the example shown above. [1] https://docs.amd.com/category/ROCm_v5.4 [2] https://docs.amd.com/bundle/HIP-Programming-Guide-v5.4 [3] https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads [4] https://docs.amd.com/bundle/ROCDebugger-API-Guide-v5.4 Change-Id: I591edca98b8927b1e49e4b0abe4e304765fed9ee Co-Authored-By: Zoran Zaric <zoran.zaric@amd.com> Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com> Co-Authored-By: Tony Tye <Tony.Tye@amd.com> Co-Authored-By: Lancelot SIX <lancelot.six@amd.com> Co-Authored-By: Pedro Alves <pedro@palves.net>
* gdb: Add per-remote target variables for memory read and write configChristina Schimpe2023-01-301-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds per-remote target variables for the configuration of memory read- and write packet size. It is a further change to commit "gdb: Make global feature array a per-remote target array" to apply the fixme notes described in commit 5b6d1e4 "Multi-target support". The former global variables for that configuration are still available to allow the command line configuration for all future remote connections. Similar to the command line configuration of the per- remote target feature array, the commands - set remotewritesize (deprecated) - set remote memory-read-packet-size - set remote memory-write-packet-size will configure the current target (if available). If no target is available, the default configuration for future remote connections is adapted. The show command will display the current remote target's packet size configuration. If no remote target is selected, the default configuration for future connections will be shown. It is required to adapt the test gdb.base/remote.exp which is failing for --target_board=native-extended-gdbserver. With that board GDB connects to gdbserver at gdb start time. Due to this patch two loggings "The target may not be able to.." are shown if the command 'set remote memory-write-packet-size fixed' is executed while a target is connected for the current inferior. To fix this, the clean_restart command is moved to a later time point of the test. It is sufficient to be connected to the server when "runto_main" is executed. Now the connection time is similar to a testrun with --target_board=native-gdbserver. To allow the user to distinguish between the packet-size configuration for future remote connections and for the currently selected target, the commands' loggings are adapted.
* gdb: Make global feature array a per-remote target arrayChristina Schimpe2023-01-301-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch applies the appropriate FIXME notes described in commit 5b6d1e4 "Multi-target support". "You'll notice that remote.c includes some FIXME notes. These refer to the fact that the global arrays that hold data for the remote packets supported are still globals. For example, if we connect to two different servers/stubs, then each might support different remote protocol features. They might even be different architectures, like e.g., one ARM baremetal stub, and a x86 gdbserver, to debug a host/controller scenario as a single program. That isn't going to work correctly today, because of said globals. I'm leaving fixing that for another pass, since it does not appear to be trivial, and I'd rather land the base work first. It's already useful to be able to debug multiple instances of the same server (e.g., a distributed cluster, where you have full control over the servers installed), so I think as is it's already reasonable incremental progress." Using this patch it is possible to configure per-remote targets' feature packets. Given the following setup for two gdbservers: ~~~~ gdbserver --multi :1234 gdbserver --disable-packet=vCont --multi :2345 ~~~~ Before this patch configuring of range-stepping was not possible for one of two connected remote targets with different support for the vCont packet. As one of the targets supports vCont, it should be possible to configure "set range-stepping". However, the output of GDB looks like: (gdb) target extended-remote :1234 Remote debugging using :1234 (gdb) add-inferior -no-connection [New inferior 2] Added inferior 2 (gdb) inferior 2 [Switching to inferior 2 [<null>] (<noexec>)] (gdb) target extended-remote :2345 Remote debugging using :2345 (gdb) set range-stepping on warning: Range stepping is not supported by the current target (gdb) inferior 1 [Switching to inferior 1 [<null>] (<noexec>)] (gdb) set range-stepping on warning: Range stepping is not supported by the current target ~~~~ Two warnings are shown. The warning for inferior 1 should not appear as it is connected to a target supporting the vCont package. ~~~~ (gdb) target extended-remote :1234 Remote debugging using :1234 (gdb) add-inferior -no-connection [New inferior 2] Added inferior 2 (gdb) inferior 2 [Switching to inferior 2 [<null>] (<noexec>)] (gdb) target extended-remote :2345 Remote debugging using :2345 (gdb) set range-stepping on warning: Range stepping is not supported by the current target (gdb) inferior 1 [Switching to inferior 1 [<null>] (<noexec>)] (gdb) set range-stepping on (gdb) ~~~~ Now only one warning is shown for inferior 2, which is connected to a target not supporting vCont. The per-remote target feature array is realized by a new class remote_features, which stores the per-remote target array and provides functions to determine supported features of the target. A remote_target object now has a new member of that class. Each time a new remote_target object is initialized, a new per-remote target array is constructed based on the global remote_protocol_packets array. The global array is initialized in the function _initialize_remote and can be configured using the command line. Before this patch the command line configuration affected current targets and future remote targets (due to the global feature array used by all remote targets). This behavior is different and the configuration applies as follows: - If a target is connected, the command line configuration affects the current connection. All other existing remote targets are not affected. - If not connected, the command line configuration affects future connections. The show command displays the current remote target's configuration. If no remote target is selected the default configuration for future connections is shown. If we have for instance the following setup with inferior 2 being selected: ~~~~ (gdb) info inferiors Num Description Connection Executable 1 <null> 1 (extended-remote :1234) * 2 <null> 2 (extended-remote :2345) ~~~~ Before this patch, if we run 'set remote multiprocess-feature-packet', the following configuration was set: The feature array of all remote targets (in this setup the two connected targets) and all future remote connections are affected. After this patch, it will be configured as follows: The feature array of target with port :2345 which is currently selected will be configured. All other existing remote targets are not affected. The show command 'show remote multiprocess-feature-packet' will display the configuration of target with port :2345. Due to this configuration change, it is required to adapt the test "gdb/testsuite/gdb.multi/multi-target-info-inferiors.exp" to configure the multiprocess-feature-packet before the connections are created. To inform the gdb user about the new behaviour of the 'show remote PACKET-NAME' commands and the new configuration impact for remote targets using the 'set remote PACKET-NAME' commands the commands' outputs are adapted. Due to this change it is required to adapt each test using the set/show remote 'PACKET-NAME' commands.
* GDB: Add a character string limiting optionAndrew Burgess2023-01-191-5/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit splits the `set/show print elements' option into two. We retain `set/show print elements' for controlling how many elements of an array we print, but a new `set/show print characters' setting is added which is used for controlling how many characters of a string are printed. The motivation behind this change is to allow users a finer level of control over how data is printed, reflecting that, although strings can be thought of as arrays of characters, users often want to treat these two things differently. For compatibility reasons by default the `set/show print characters' option is set to `elements', which makes the limit for character strings follow the setting of the `set/show print elements' option, as it used to. Using `set print characters' with any other value makes the limit independent from the `set/show print elements' setting, however it can be restored to the default with the `set print characters elements' command at any time. A corresponding `-characters' option for the `print' command is added, with the same semantics, i.e. one can use `elements' to make a given `print' invocation follow the limit of elements, be it set with the `-elements' option also given with the same invocation or taken from the `set/show print elements' setting, for characters as well regardless of the current setting of the `set/show print characters' option. The GDB changes are all pretty straightforward, just changing references to the old 'print_max' to use a new `get_print_max_chars' helper which figures out which of the two of `print_max' and `print_max_chars' values to use. Likewise, the documentation is just updated to reference the new setting where appropriate. To make people's life easier the message shown by `show print elements' now indicates if the setting also applies to character strings: (gdb) set print characters elements (gdb) show print elements Limit on string chars or array elements to print is 200. (gdb) set print characters unlimited (gdb) show print elements Limit on array elements to print is 200. (gdb) and the help text shows the dependency as well: (gdb) help set print elements Set limit on array elements to print. "unlimited" causes there to be no limit. This setting also applies to string chars when "print characters" is set to "elements". (gdb) In the testsuite there are two minor updates, one to add `-characters' to the list of completions now shown for the `print' command, and a bare minimum pair of checks for the right handling of `set print characters' and `show print characters', copied from the corresponding checks for `set print elements' and `show print elements' respectively. Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
* gdb/doc: use @value{GDBP} in some spotsSimon Marchi2023-01-101-117/+117
| | | | | | | | Examples are supposed to use @value{GDBP} instead of the literal "(gdb)" (many of them already do). Update a bunch of spots where it wasn't the case. Change-Id: I601adaad61fd277a5fceea1759e49cede72e456d
* gdb/doc: use @value{GDBN} in some spotsSimon Marchi2023-01-101-4/+4
| | | | | | Change some spots to use "@value{GDBN}" instead of just "GDB". Change-Id: I3fc26438e603538271cf33e4d148be5fda9ece7e
* gdb/doc: some whitespace fixesSimon Marchi2023-01-101-22/+22
| | | | | | For consistency, replace tabs with spaces in all gdb.texinfo menus. Change-Id: I0801a72cf82a8afe49ec842244f42d30719634ce
* gdb/mi: add no-history stop reasonBruno Larsen2023-01-061-0/+2
| | | | | | | | | | | | | | | | | When executing in reverse and runs out of recorded history, GDB prints a warning to the user, but does not add a reason in the stopped record, for example: *stopped,frame={addr="0x000000000040113e",func="main",args=[],file="/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",fullname="/home/blarsen/Documents/binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",line="27",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1" This problem was reported as record/29260. This commit adds the reason no-history to the record, making it easier for interfaces using the mi interpreter to report the result. It also changes the test gdb.mi/mi-reverse.exp to test that the reason shows up correctly. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29260
* gdb: add 'maintenance print record-instruction' commandBruno Larsen2023-01-041-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | While chasing some reverse debugging bugs, I found myself wondering what was recorded by GDB to undo and redo a certain instruction. This commit implements a simple way of printing that information. If there isn't enough history to print the desired instruction (such as when the user hasn't started recording yet or when they request 2 instructions back but only 1 was recorded), GDB warns the user like so: (gdb) maint print record-instruction Not enough recorded history If there is enough, GDB prints the instruction like so: (gdb) maint print record-instruction 4 bytes of memory at address 0x00007fffffffd5dc changed from: 01 00 00 00 Register eflags changed: [ IF ] Register rip changed: (void (*)()) 0x401115 <main+15> Approved-by: Eli Zaretskii <eliz@gnu.org> Reviewed-by: Alexandra Hajkova <ahajkova@redhat.com> Reviewed-by: Lancelot Six <lsix@lancelotsix.com> Approved-by: Tom Tromey <tom@tromey.com>
* Initial implementation of Debugger Adapter ProtocolTom Tromey2023-01-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use to communicate with debuggers. You can find more information here: https://microsoft.github.io/debug-adapter-protocol/ Frequently this is implemented as a shim, but it seemed to me that GDB could implement it directly, via the Python API. This patch is the initial implementation. DAP is implemented as a new "interp". This is slightly weird, because it doesn't act like an ordinary interpreter -- for example it doesn't implement a command syntax, and doesn't use GDB's ordinary event loop. However, this seemed like the best approach overall. To run GDB in this mode, use: gdb -i=dap The DAP code will accept JSON-RPC messages on stdin and print responses to stdout. GDB redirects the inferior's stdout to a new pipe so that output can be encapsulated by the protocol. The Python code uses multiple threads to do its work. Separate threads are used for reading JSON from the client and for writing JSON to the client. All GDB work is done in the main thread. (The first implementation used asyncio, but this had some limitations, and so I rewrote it to use threads instead.) This is not a complete implementation of the protocol, but it does implement enough to demonstrate that the overall approach works. There is a rudimentary test suite. It uses a JSON parser written in pure Tcl. This parser is under the same license as Tcl itself, so I felt it was acceptable to simply import it into the tree. There is also a bit of documentation -- just documenting the new interpreter name.
* manual copyright year range of various GDB files to add 2023Joel Brobecker2023-01-011-2/+2
| | | | | | | | | | | | | This commit updates the following file... gdb/doc/gdb.texinfo gdb/doc/refcard.tex gdb/syscalls/update-netbsd.sh ... by hand as instructed by the gdb/copyright.py script. The update by hand is needed because the copyright headers to update are actually nested inside those files, rather than located at the start of the file.
* Update copyright year range in header of all files managed by GDBJoel Brobecker2023-01-011-1/+1
| | | | | | | This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
* [gdb/cli] Add maintenance ignore-probesTom de Vries2022-12-311-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a command "disable probes", but SystemTap probes, for instance libc:longjmp cannot be disabled: ... $ gdb -q -batch a.out -ex start -ex "disable probes libc ^longjmp$" ... Probe libc:longjmp cannot be disabled. Probe libc:longjmp cannot be disabled. Probe libc:longjmp cannot be disabled. ... Add a command "maintenance ignore-probes" that ignores probes during get_probes, such that we can easily pretend to use a libc without the libc:longjmp probe: ... (gdb) maint ignore-probes -verbose libc ^longjmp$ ignore-probes filter has been set to: PROVIDER: 'libc' PROBE_NAME: '^longjmp$' OBJNAME: '' (gdb) start ^M ... Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M Ignoring SystemTap probe libc longjmp in /lib64/libc.so.6.^M ... The "Ignoring ..." messages can be suppressed by not using -verbose. Note that as with "disable probes", running simply "maint ignore-probes" ignores all probes. The ignore-probes filter can be reset by using: ... (gdb) maint ignore-probes -reset ignore-probes filter has been reset ... For now, the command is only supported for SystemTap probes. PR cli/27159 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27159
* Use toplevel configure for GMP and MPFR for gdbAndrew Pinski2022-12-211-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch uses the toplevel configure parts for GMP/MPFR for gdb. The only thing is that gdb now requires MPFR for building. Before it was a recommended but not required library. Also this allows building of GMP and MPFR with the toplevel directory just like how it is done for GCC. We now error out in the toplevel configure of the version of GMP and MPFR that is wrong. OK after GDB 13 branches? Build gdb 3 ways: with GMP and MPFR in the toplevel (static library used at that point for both) With only MPFR in the toplevel (GMP distro library used and MPFR built from source) With neither GMP and MPFR in the toplevel (distro libraries used) Changes from v1: * Updated gdb/README and gdb/doc/gdb.texinfo. * Regenerated using unmodified autoconf-2.69 Thanks, Andrew Pinski ChangeLog: * Makefile.def: Add configure-gdb dependencies on all-gmp and all-mpfr. * configure.ac: Split out MPC checking from MPFR. Require GMP and MPFR if the gdb directory exist. * Makefile.in: Regenerate. * configure: Regenerate. gdb/ChangeLog: PR bug/28500 * configure.ac: Remove AC_LIB_HAVE_LINKFLAGS for gmp and mpfr. Use GMPLIBS and GMPINC which is provided by the toplevel configure. * Makefile.in (LIBGMP, LIBMPFR): Remove. (GMPLIBS, GMPINC): Add definition. (INTERNAL_CFLAGS_BASE): Add GMPINC. (CLIBS): Exchange LIBMPFR and LIBGMP for GMPLIBS. * target-float.c: Make the code conditional on HAVE_LIBMPFR unconditional. * top.c: Remove code checking HAVE_LIBMPFR. * configure: Regenerate. * config.in: Regenerate. * README: Update GMP/MPFR section of the config options. * doc/gdb.texinfo: Likewise. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28500
* Remove MI version 1Tom Tromey2022-12-191-4/+0
| | | | | | | | MI version 1 is long since obsolete. Several years ago, I filed PR mi/23170 for this. I think it's finally time to remove this. Any users of MI 1 can and should upgrade to a newer version. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23170
* gdb/maint: add core file name to 'maint info program-spaces' outputAndrew Burgess2022-12-141-2/+6
| | | | | Each program space can have an associated core file. Include this information in the output of 'maint info program-spaces'.
* gdb: merge solib-frv aix-solib debug options into "set/show debug solib"Simon Marchi2022-12-021-13/+5
| | | | | | | | | | | solib implementations are typically used one at a time. So it will be rare that you will want to enable debug for one solib kind, and absolutely want to keep the others disabled. To make things simpler, instead of adding separate variables / macros / commands for each solib implementation, merge the existing ones (frv and aix) into a unified "set/show debug solib", with the solib_debug_printf macro. Change-Id: I6e18bbc7401724f37ae66681badb079d75ecf7fa
* Show locno for 'multi location' breakpoint hit msg+conv var $_hit_bbnum ↵Philippe Waroquiers2022-11-191-3/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | $_hit_locno PR breakpoints/12464 This implements the request given in PR breakpoints/12464. Before this patch, when a breakpoint that has multiple locations is reached, GDB printed: Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5 This patch changes the message so that bkpt_print_id prints the precise encountered breakpoint: Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5 In mi mode, bkpt_print_id also (optionally) prints a new table field "locno": locno is printed when the breakpoint hit has more than one location. Note that according to the GDB user manual node 'GDB/MI Development and Front Ends', it is ok to add new fields without changing the MI version. Also, when a breakpoint is reached, the convenience variables $_hit_bpnum and $_hit_locno are set to the encountered breakpoint number and location number. $_hit_bpnum and $_hit_locno can a.o. be used in the command list of a breakpoint, to disable the specific encountered breakpoint, e.g. disable $_hit_bpnum.$_hit_locno In case the breakpoint has only one location, $_hit_locno is set to the value 1, so as to allow a command such as: disable $_hit_bpnum.$_hit_locno to disable the breakpoint even when the breakpoint has only one location. This also fixes a strange behaviour: when a breakpoint X has only one location, enable|disable X.1 is accepted but transforms the breakpoint in a multiple locations breakpoint having only one location. The changes in RFA v4 handle the comments of Tom Tromey: - Changed convenience var names from $bkptno/$locno to $_hit_bpnum/$_hit_locno. - updated the tests and user manual accordingly. User manual also explictly describes that $_hit_locno is set to 1 for a breakpoint with a single location. - The variable values are now set in bpstat_do_actions_1 so that they are set for silent breakpoints, and when several breakpoints are hit at the same time, that the variables are set to the printed breakpoint. The changes in RFA v3 handle the additional comments of Eli: GDB/NEW: - Use max 80-column - Use 'code location' instead of 'location'. - Fix typo $bkpno - Ensure that disable $bkptno and disable $bkptno.$locno have each their explanation inthe example - Reworded the 'breakpoint-hit' paragraph. gdb.texinfo: - Use 'code location' instead of 'location'. - Add a note to clarify the distinction between $bkptno and $bpnum. - Use @kbd instead of examples with only one command. Compared to RFA v1, the changes in v2 handle the comments given by Keith Seitz and Eli Zaretskii: - Use %s for the result of paddress - Use bkptno_numopt_re instead of 2 different -re cases - use C@t{++} - Add index entries for $bkptno and $locno - Added an example for "locno" in the mi interface - Added examples in the Break command manual.
View Lorry Controller Status