aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2025-02-19gdb/mi: Fix segfault when attaching a rocm process with MILancelot Six3-1/+71
When using the MI interpreter, if someone was to attach to a ROCm process which has active GPU waves, GDB would issue a segfault as follows: attach 1994813 &"attach 1994813\n" ~"Attaching to process 1994813\n" =thread-group-started,id="i1",pid="1994813" =thread-created,id="1",group-id="i1" =thread-created,id="2",group-id="i1" ~"[New LWP 1994828]\n" *running,thread-id="2" =thread-created,id="3",group-id="i1" ~"[New LWP 1994825]\n" *running,thread-id="3" =thread-created,id="4",group-id="i1" ~"[New LWP 1994823]\n" *running,thread-id="4" ^done =library-loaded,... [...] ~"[Thread debugging using libthread_db enabled]\n" ~"Using host libthread_db library \"/lib/x86_64-linux-gnu/libthread_db.so.1\".\n" =thread-created,id="5",group-id="i1" &"\n\n" &"Fatal signal: " &"Segmentation fault" &"\n" &"----- Backtrace -----\n" &"Backtrace unavailable\n" &"---------------------\n" &"A fatal error internal to GDB has been detected, further\ndebugging is not possible. GDB will now terminate.\n\n" &"This is a bug, please report it." &" For instructions, see:\n" &"<https://github.com/ROCm-Developer-Tools/ROCgdb/issues>" &"." &"\n\n" Segmentation fault The issue comes from using a non-initialized pointer in mi_on_resume_1: if (!mi->running_result_record_printed && mi->mi_proceeded) { gdb_printf (mi->raw_stdout, "%s^running\n", mi->current_token ? mi->current_token : ""); } In this instance, "mi->current_token" has an uninitialized value. This is a regression introduced by: commit def2803789208a617c429b5dcf2026decb25ce0c Date: Wed Sep 6 11:02:00 2023 -0400 gdb/mi: make current_token a field of mi_interp Before this patch, current_token was a global implicitly 0-initialized. Since it is now a class field, it is not 0-initialized by default anymore. This patch changes this. Change-Id: I3f00b080318a70405d881ff0abe02b2c5cb1f9d8 Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com>
2025-02-19gdb/dwarf: add logging for CU expansionSimon Marchi1-6/+36
I was trying to get an understanding of which CUs were expanded when, and how much time it was taking. I wrote this patch to add some logging related to that, and I think it would be useful to have upstream, to better understand performance problems related to over-eager CU expansion, for example. - add DWARF_READ_SCOPED_DEBUG_START_END - use it in process_queue, to wrap the related expansion messages together - add a message in maybe_queue_comp_unit when enqueuing a comp unit - add timing information to messages in process_queue, indicating how much time it took to expand a given symtab - count the number of expansions done in a single call to process_queue [dwarf-read] process_queue: start: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ... [dwarf-read] process_queue: Expanding symtab of CU at offset 0xc [dwarf-read] maybe_queue_comp_unit: Queuing CU for expansion: section offset = 0x38b, queue size = 2 [dwarf-read] process_queue: Done expanding CU at offset 0xc, took 0.001s [dwarf-read] process_queue: Expanding symtab of CU at offset 0x38b [dwarf-read] process_queue: Done expanding CU at offset 0x38b, took 0.000s [dwarf-read] process_queue: Done expanding 2 symtabs. [dwarf-read] process_queue: end: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ... Change-Id: I5237d50e0c1d06be33ea83a9120b5fe1cf7ab8c2 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-19gdb/dwarf: set is_debug_types in signatured_type constructorSimon Marchi2-3/+3
This makes it more obvious that all created signatured_type objects have this flag set. Also, remove an unnecessary assignment in create_cus_hash_table: when constructing the dwarf2_per_cu_data object, is_debug_types is already initialized to 0/false. Change-Id: I6d28b17ac77edc040172254f6970d05ebc4a47f4 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-19gdb/dwarf: pass section to dwarf2_per_cu_data constructorSimon Marchi3-31/+39
Same as the previous patch, but for the containing section. Change-Id: I469147cce21525d61b3cf6edd9a9f4b12027c176 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-19gdb/dwarf: pass section offset to dwarf2_per_cu_data constructorSimon Marchi3-36/+42
Similar to the previous patch, but for the offset within the containing section. Change-Id: I1d76e1f88002bca924e0b12fd78c7ea49d36c0ec Approved-By: Tom Tromey <tom@tromey.com>
2025-02-19gdb/dwarf: pass dwarf2_per_bfd to dwarf2_per_cu_data constructorSimon Marchi2-20/+18
Pass a dwarf2_per_bfd to the constructor of dwarf2_per_cu_data and set the per_bfd field there. All "real" instantiations of dwarf2_per_cu_data must have a valid, non-nullptr dwarf2_per_bfd backlink, this makes it a bit more obvious. The instantiations of dwarf2_per_cu_data that receive a nullptr dwarf2_per_bfd are the ones used to do hash map lookups and the ones used in selftests. Remove an unnecessary assignment of per_bfd in fill_in_sig_entry_from_dwo_entry: the per_bfd field is already set when the signatured_type object is constructor (before that, it was set in allocate_signatured_type). Change-Id: Ifeebe55fdb1bc2de4de9c852033fafe8abdfde8a Approved-By: Tom Tromey <tom@tromey.com>
2025-02-19gdb/dwarf: change some functions from "per objfile" to "per bfd"Simon Marchi1-82/+77
I noticed that the following functions accept a "dwarf2_per_objfile", but they can actually accept a less specific "dwarf2_per_bfd". This makes it more obvious that the work they do is per BFD and not per objfile. - add_type_unit - lookup_dwo_file_slot - create_dwo_unit_in_dwp_v1 - create_dwp_v2_or_v5_section - create_dwo_unit_in_dwp_v2 - create_dwo_unit_in_dwp_v5 - lookup_dwo_unit_in_dwp Change-Id: I200cd77850ce0ffa29fc1b9d924056fdce2559f8 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-19gdb/dwarf: std::unordered_{set,map} -> gdb::unordered_{set,map} throughoutSimon Marchi8-35/+27
No behavior changes expected. Change-Id: I16ff6c67058362c65cc8edb05d1948e48be6b2e1 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-19gdb/remote: don't error if qGetTIBAddr is unsupportedQwinci1-4/+2
This change makes it possible to debug PE executables run in e.g. Qemu without needing to set osabi to none, it breaks backtrace and commands like finish if frame pointers are not present but SEH unwind info is. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-19gdb: LoongArch: Extend the maximum number of hardware watchpointsHui Li2-3/+3
The maximum number of load/store watchpoints and fetch instruction watchpoints is 14 each according to LoongArch Reference Manual [1], so extend the maximum number of hardware watchpoints from 8 to 14. A new struct user_watch_state_v2 was added into uapi in the related kernel commit 531936dee53e ("LoongArch: Extend the maximum number of watchpoints") [2], but there may be no struct user_watch_state_v2 in the system header in time. Modify the struct loongarch_user_watch_state in GDB which is same with the uapi struct user_watch_state_v2. As far as I can tell, the only users for this struct in the userspace are GDB and LLDB, there are no any problems of software compatibility between the application and kernel according to the analysis. The compatibility problem has been considered while developing and testing. When the applications in the userspace get watchpoint state, the length will be specified which is no bigger than the sizeof struct user_watch_state or user_watch_state_v2, the actual length is assigned as the minimal value of the application and kernel in the generic code of ptrace: kernel/ptrace.c: ptrace_regset(): kiov->iov_len = min(kiov->iov_len, (__kernel_size_t) (regset->n * regset->size)); if (req == PTRACE_GETREGSET) return copy_regset_to_user(task, view, regset_no, 0, kiov->iov_len, kiov->iov_base); else return copy_regset_from_user(task, view, regset_no, 0, kiov->iov_len, kiov->iov_base); For example, there are four kind of combinations, all of them work well. (1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200; (2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344; (3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200; (4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200. BTW, LLDB also made this change in the related commit ff79d83caeee ("[LLDB][LoongArch] Extend the maximum number of watchpoints") [3] [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=531936dee53e [3] https://github.com/llvm/llvm-project/commit/ff79d83caeee Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2025-02-19gdbserver, remote: introduce "id_str" in the "qXfer:threads:read" XMLTankut Baris Aktemur3-3/+38
GDB prints the target id of a thread in various places such as the output of the "info threads" command in the "Target Id" column or when switching to a thread. A target can define what to print for a given ptid by overriding the `pid_to_str` method. The remote target is a gateway behind which one of many various targets could be running. The remote target converts a given ptid to a string in a uniform way, without consulting the low target at the server-side. In this patch we introduce a new attribute in the XML that is sent in response to the "qXfer:threads:read" RSP packet, so that a low target at the server side, if it wishes, can specify what to print as the target id of a thread. Note that the existing "name" attribute or the "extra" text provided in the XML are not sufficient for the server-side low target to achieve the goal. Those attributes, when present, are simply appended to the target id by GDB. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-02-18testsuite, mi: prevent buffer overflow in get_mi_thread_listTankut Baris Aktemur1-25/+26
If there is a large number of threads in the input program, the expect buffer in `get_mi_thread_list` would become full. Prevent this by consuming the buffer in small pieces. Regression-tested using the gdb.mi tests. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-02-18[gdb/testsuite] Don't start gdb in gdb.base/gstack.expTom de Vries1-2/+2
In test-case gdb.base/gstack.exp we start a gdb implicitly using prepare_for_testing. The gdb is not really used, but its spawn_id (available in variable gdb_spawn_id) is used in a gdb_test_multiple, which is used to interact with the gstack process. Usually, a running gdb is cleaned up at test-case exit in gdb_finish, which calls gdb_exit, which by default calls gdb_default_exit, which does 'send_gdb "quit\n"'. However, this sends a quit to the host process expect is currently talking to, defined by board_info(host,fileid), and after spawning gstack that's gstack, not gdb. Fix this by: - using build_executable instead of prepare_for_testing to not spawn an unused gdb, and - changing the gdb_test_multiple into a gdb_expect, eliminating the implicit use of gdb_spawn_id. Tested on x86_64-linux. Reviewed-By: Keith Seitz <keiths@redhat.com> PR testsuite/32709 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32709
2025-02-18[gdb] Fix some typosTom de Vries5-7/+7
Fix typos: ... overriden -> overridden reate -> create ... Tested on x86_64-linux. I
2025-02-17gdb/dwarf: make maybe_queue_comp_unit return boolSimon Marchi1-2/+2
Change-Id: I9a6bf27b72f7efb1cc4cea5345db14969e794bdb
2025-02-17gdb/dwarf: remove spurious spaceSimon Marchi1-1/+1
Change-Id: I420280721cb734a2e061743309bf9b25d2179f8f
2025-02-17gdb: remove unused include in symfile-debug.cSimon Marchi1-1/+0
This is reported as unused by clangd. Change-Id: Ida5a93b632cd4477fb91df1ab0edf66f12a28f64
2025-02-17gdb: remove unused include in objfiles.hSimon Marchi1-1/+0
clangd reports this include as unused. Change-Id: I6a4224d8aa581fea2336da124c89ade09f573af3
2025-02-17testsuite, mi: fix indentation in get_mi_thread_listTankut Baris Aktemur1-29/+29
The `get_mi_thread_list` procedure's body is incorrectly indented. Fix it. There is one line that was already long. Consider it an exception and don't bother breaking it.
2025-02-16gdb: fix color_option_def compile error (clang)Andrew Oates1-1/+1
color_option_def was added in commit 6447969d0 ("Add an option with a color type."), but not used. The color_option_def constructor passes the wrong number of arguments to the option_def constructor. Since color_option_def is a template and never actually instantiated, GCC does not fail to compile this. clang generates an error (see below). This passes nullptr to the extra_literals_ option_def ctor argument, which matches what filename_option_def above it does. clang's generated error: ../../gdb/cli/cli-option.h:343:7: error: no matching constructor for initialization of 'option_def' : option_def (long_option_, var_color, ^ ~~~~~~~~~~~~~~~~~~~~~~~~ ../../gdb/cli/cli-option.h:50:13: note: candidate constructor not viable: requires 8 arguments, but 7 were provided constexpr option_def (const char *name_, ^ ../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 7 were provided struct option_def ^ ../../gdb/cli/cli-option.h:37:8: note: candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 7 were provided Approved-By: Tom de Vries <tdevries@suse.de>
2025-02-15alpha, ld: remove -taso optionIvan Kokshaysky1-6/+0
The -taso switch was quite useful 25 years ago for porting 32-bit code with broken integer-pointer casting. Not anymore. The EF_ALPHA_32BIT Linux support is going to be dropped in kernel v6.14 [1], NetBSD and OpenBSD never had it, so there is no point in keeping the -taso option around. Also remove alpha special case that uses -taso from gdb.base/dump.exp in gdb testsuite. [1] https://lore.kernel.org/all/87jzb2tdb7.fsf_-_@email.froward.int.ebiederm.org Signed-off-by: Ivan Kokshaysky <ink@unseen.parts> Reviewed-By: Maciej W. Rozycki <macro@orcam.me.uk> Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-02-14gdb/testsuite: clean ups in gdb.python/py-source-styling.expAndrew Burgess1-8/+8
The top comment in gdb.python/py-source-styling.exp was completely wrong, clearly a cut&paste job from elsewhere. Write a comment that actually reflects what the test does. I've also moved the allow_python_tests check earlier in the file. And I changed some 'return -1' into just 'return'. I'm not aware that the '-1' adds any value. I also folded a 'pass $gdb_test_name' into the preceding gdb_assert, which I think is neater. There is no change in what is actually being tested after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-14gdb/tui: use maybe_update for source centring in an extra caseAndrew Burgess3-1/+89
I noticed that, with recent versions of GDB, when the TUI is enabled before the inferior is started, the source code display is not as helpful as it used to be. Here's a simple test program being displayed using GDB 15.2, at this point the inferior has not started, all I've done is 'tui enable': ┌─hello.c────────────────────────────────────────────────┐ │ 10 return 0; │ │ 11 } │ │ 12 │ │ 13 /* The main function. */ │ │ 14 │ │ 15 int │ │ 16 main () │ │ 17 { │ │ 18 printf ("Hello World\n"); │ │ 19 call_me ( 0, 1, 2, 3, 4, 5, 6, 7 ); │ │ 20 return 0; │ │ 21 } │ │ │ │ │ └────────────────────────────────────────────────────────┘ Compare this to GDB 16.2: ┌─hello.c────────────────────────────────────────────────┐ │ 17 { │ │ 18 printf ("Hello World\n"); │ │ 19 call_me ( 0, 1, 2, 3, 4, 5, 6, 7 ); │ │ 20 return 0; │ │ 21 } │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └────────────────────────────────────────────────────────┘ I think the new layout is not as good because it is missing the context of the function name. The new behaviour started with the commit: commit 49e607f511c1fab82a0116990a72d1915c74bb4a Author: Stephan Rohr <stephan.rohr@intel.com> Date: Sat Aug 3 02:07:42 2024 -0700 gdb: adjust the default place of 'list' to main's prologue I don't think the new behaviour is really a problem with that commit, rather, when using 'tui enable' before the inferior has started GDB ends up calling tui_source_window_base::rerender(), and then passes through the code path which calls update_source_window_with_addr(). When using 'tui enable' after the inferior has started, GDB again calls tui_source_window_base::rerender(), but this time has a frame, and so takes the second code path, which centres the selected source line, and then calls update_source_window. The point is that the update_source_window_with_addr() path doesn't include the logic to centre the source line. Before the above commit this was fine as GDB's default location would be prior to main, and so we got the "good" TUI output. After the above commit the default location is now main's prologue, and without the centring logic, the first line shown is main's prologue. I propose fixing this by having update_source_window_with_addr() call maybe_update(). This will first check if the requested line is already visible, and if not, show the requested line with centring applied. After this commit, the 'tui enable' state is now: ┌─hello.c─────────────────────────────────────────────────────┐ │ 11 } │ │ 12 │ │ 13 /* The main function. */ │ │ 14 │ │ 15 int │ │ 16 main () │ │ 17 { │ │ 18 printf ("Hello World\n"); │ │ 19 call_me ( 0, 1, 2, 3, 4, 5, 6, 7 ); │ │ 20 return 0; │ │ 21 } │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────┘ It's not identical to the old behaviour, but that was never the objective, we do however, see the context around main's prologue, which will usually be enough to see the function name and return type, which I think is useful. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-14gdb/tui: update maybe_update to take gdbarchAndrew Burgess6-12/+11
This is a refactor to setup for the next commit. The maybe_update function currently takes a frame_info_ptr&, however, it only uses this to get the frame's gdbarch. In the next commit I want to call maybe_update when I have a gdbarch, but no frame_info_ptr& (the inferior hasn't even started). So, update maybe_update to take the gdbarch, and update the callers to pass that through. Most callers already have the gdbarch to hand, but in one place I do need to extract this from the frame_info_ptr&. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-14Handle DW_FORM_data4 in read-debug-names.cTom Tromey1-3/+17
The recent .debug_names patches caused the writer to emit DW_FORM_data4. Unfortunately the reader did not handle this form. This patch updates the reader to handle a few DW_FORM_data* forms. The complaint that is there went unnoticed -- I only found this when debugging a failure in another series. More evidence, IMO, that complaints should be removed. I think the reason the failure itself went unnoticed is that the symbol table code in gdb often works by accident, and in particular in small programs like the ones in the test suite, it's often the case that a CU will be expanded for some other reason, causing the test to pass without really touching the index code. The aforementioned series is aimed at fixing this. It would probably be good to unify the abbrev/form code to some degree, but it's mildly a pain as some forms don't make sense here and because we recently discovered other issues with gdb's DW_FORM_data* handling. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-02-14gdb/dwarf: unique_ptr cleanupSimon Marchi14-55/+67
Throughout gdb/dwarf2, use `*_up` typedefs. Add a few missing typedefs, and move some so they are, ideally, just after the corresponding class. Change-Id: Iab5cd8fc2e9989d4bd8d4868586703c2312f254f Approved-By: Tom Tromey <tom@tromey.com>
2025-02-14gdb/dwarf: rename cooked_index_worker subclassesSimon Marchi2-10/+10
Rename them to include "worker" in the name. Otherwise, it's easy to be confused and think that they are sub-classes of "cooked_index". Change-Id: I625ef076f9485f3873db530493f60a53d02c1991 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-14gdb/dwarf: use term "shard" instead of "index"Simon Marchi2-10/+11
A bit more changes as in 8e745eac7db3 ("gdb/dwarf: rename cooked_index::m_vector to m_shards"). I think it's clearer if the term "index" is reserved for the whole thing, while "shard" or "index shard" are used for the parts. Change-Id: I457bb0016a70f3f9918f4a3c3977262a7801705b Approved-By: Tom Tromey <tom@tromey.com>
2025-02-14gdb/python/dap: prefix internal attributes with underscoreSimon Marchi7-118/+116
I'm currently reading the DAP code, and I think this would help. This is pretty much standard Python style, we do it as some places but not others. I think it helps readability, by saying that this attribute isn't mean to be accessed outside the class. A similar pass could be done for internal methods, I haven't done that. Change-Id: I8e8789b39adafe62d14404d19f7fc75e2a364e01 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-14gdb: only update m_last_subfile after writing a line table entryAndrew Burgess3-3/+264
While working on another patch which changes how we parse the line DWARF line tables I noticed what I think is a minor bug in how we process the line tables. What I noticed is that my new line table parser was adding more END markers into the parsed table than GDB's current approach. This difference was observed when processing the debug information for libstdc++. Here is the line table from the new test, this is a reasonable reproduction of the problem case that I observed in the actual debug line table: Contents of the .debug_line section: dw2-skipped-line-entries-1.c: File name Line number Starting address View Stmt dw2-skipped-line-entries-1.c 101 0x40110a x /tmp/dw2-skipped-line-entries-2.c: dw2-skipped-line-entries-2.c 201 0x401114 x /tmp/dw2-skipped-line-entries-3.c: dw2-skipped-line-entries-3.c 301 0x40111e x /tmp/dw2-skipped-line-entries-1.c: dw2-skipped-line-entries-1.c 102 0x401128 x dw2-skipped-line-entries-1.c 103 0x401128 x dw2-skipped-line-entries-1.c 104 0x401128 x /tmp/dw2-skipped-line-entries-2.c: dw2-skipped-line-entries-2.c 211 0x401128 /tmp/dw2-skipped-line-entries-3.c: dw2-skipped-line-entries-3.c 311 0x401132 /tmp/dw2-skipped-line-entries-1.c: dw2-skipped-line-entries-1.c 104 0x40113c dw2-skipped-line-entries-1.c 105 0x401146 x dw2-skipped-line-entries-1.c - 0x401150 The problem is caused by the entry for line 211. Notice that this entry is at the same address as the previous entries. Further, the entry for 211 is a non-statement entry, while the previous entries are statement entries. As the entry for line 211 is a non-statement entry, and the previous entries at that address are statement entries in a different symtab, it is thought that it is better to prefer the earlier entries (in dw2-skipped-line-entries-1.c), and so the entry for line 211 will be discarded. As GDB parses the line table it switches between the 3 symtabs (based on source filename) adding the relevant entries to each symtab. Additionally, as GDB switches symtabs, it adds an END entry to the previous symtab. The problem then is that, for the line 211 entry, this is the only entry in dw2-skipped-line-entries-2.c before we switch symtab again. But the line 211 entry is discarded. This means that GDB switches from dw2-skipped-line-entries-1.c to dw2-skipped-line-entries-2.c, and then on to dw2-skipped-line-entries-3.c without ever adding an entry to dw2-skipped-line-entries-2.c. And here then is the bug. GDB updates its idea of the previous symtab not when an entry is written into a symtab, but every time we change symtab. In this case, when we switch to dw2-skipped-line-entries-3.c we add the END marker to dw2-skipped-line-entries-2.c, even though no entries were written to dw2-skipped-line-entries-2.c. At the same time, no END marker is ever written into dw2-skipped-line-entries-1.c as the dw2-skipped-line-entries-2.c entry (for line 211) was discarded. Here is the 'maint info line-table' for dw2-skipped-line-entries-1.c before this patch: INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN 0 101 0x000000000040110a 0x000000000040110a Y 1 END 0x0000000000401114 0x0000000000401114 Y 2 102 0x0000000000401128 0x0000000000401128 Y 3 103 0x0000000000401128 0x0000000000401128 Y 4 104 0x0000000000401128 0x0000000000401128 Y 5 104 0x000000000040113c 0x000000000040113c 6 105 0x0000000000401146 0x0000000000401146 Y 7 END 0x0000000000401150 0x0000000000401150 Y And after this patch: INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN 0 101 0x000000000040110a 0x000000000040110a Y 1 END 0x0000000000401114 0x0000000000401114 Y 2 102 0x0000000000401128 0x0000000000401128 Y 3 103 0x0000000000401128 0x0000000000401128 Y 4 104 0x0000000000401128 0x0000000000401128 Y 5 END 0x0000000000401132 0x0000000000401132 Y 6 104 0x000000000040113c 0x000000000040113c 7 105 0x0000000000401146 0x0000000000401146 Y 8 END 0x0000000000401150 0x0000000000401150 Y Notice that we gained an extra entry, the END marker that was added at position #5 in the table. Now, does this matter? I cannot find any bugs that trigger because of this behaviour. So why fix it? First, the current behaviour is inconsistent, as we switch symtabs, we usually get an END marker in the previous symtab. But occasionally we don't. I don't like things that are inconsistent for no good reason. And second, as I said, I want to change the line table parsing. To do this I want to check that my new parser creates an identical table to the current parser. But my new parser naturally "fixes" this inconsistency, so I have two choices, do extra work to make my new parser bug-compatible with the current one, or fix the current one. I'd prefer to just fix the current line table parser. There's a test that includes the above example and checks that the END markers are put in the correct place. But as I said, I've not been able to trigger any negative behaviour from the current solution, so there's no test that exposes any broken behaviour. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-13Remove assumption from py-symbol.expTom Tromey1-8/+12
The current py-symbol.exp test makes an assumption about which symbol will be returned first. I don't think gdb should really make promises about the order in which the symbols are listed, though, and a series I am working on changes this behavior. This patch changes the test to merely ensure that both symbols are returned. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-02-13Update my maintenance areas in MAINTAINERS fileKevin Buettner1-5/+0
I've dropped maintenance of the mep target. Additionally, I'm removed myself as an authorized committer for PowerPC, ia64, AIX, and GNU/Linux PPC native.
2025-02-13gdb, testsuite: Rename set_sanitizer procedures to append_environment.Christina Schimpe6-16/+16
The procedures set_sanitizer_1, set_sanitizer and set_sanitizer_default are used for the configuration of ASAN specific environment variables. However, they are actually generic. Rename them to append_environment* so that their purpose is more clear. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-13aarch64: fix a crash during maintenance print cooked-registersKlaus Gerlicher1-0/+3
On aarch64 with pauth enabled a crash when can be seen when using "maintenance print cooked-registers". This happens because the register dump code tries to read a pseudo reg that is not handled here because it is supposedly only used in unwinding. Fix this by returning a zero value typed as a built-in uint64. Approved-By: Luis Machado <luis.machado@arm.com>
2025-02-12Reorder gnatmake arguments in inline-section-gc.exp, againTom Tromey1-3/+9
Tom de Vries pointed out that commit 8cfa1fc4 ("Reorder gnatmake arguments in inline-section-gc.exp") caused a regression with an older version of dejagnu. This patch works around that problem by further reordering the arguments to gnatmake and also arranging to leave gnatmake in "-margs" mode.
2025-02-12Add copyright header to gnat_debug_info_test.adbTom Tromey1-0/+15
I noticed that gdb/testsuite/lib/gnat_debug_info_test.adb is missing a copyright header. This adds one, using the date range from the original commit.
2025-02-11gdb: cleanup includes in mi/Simon Marchi10-20/+1
Remove a few includes reported as unused by clangd. Change-Id: I7365b7cce04c9ef1a4164764191303914da42ef9
2025-02-11gdb: remove check for minimal symbols in 'start_command'Rohr, Stephan1-6/+0
GDB aborts the 'start' command if the minimal symbols cannot be resolved. On Windows, GDB reads the minimal symbols from the COFF header of the PE file. The symbol table is deprecated and the number of symbols in the COFF header may be zero: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format This is reproducible with clang version 18.1.8 on Windows: clang++ -g -O0 -gdwarf -fuse-ld=lld test.cpp -o test_clang The COFF file header shows: FILE HEADER VALUES 8664 machine (x64) E number of sections 66E889EC time date stamp Mon Sep 16 21:41:32 2024 FB400 file pointer to symbol table 0 number of symbols F0 size of optional header 22 characteristics GDB is not able to read the minimal symbols; the `start' command fails with an error: (gdb) start No symbol table loaded. Use the "file" command. Manually inserting a breakpoint in main works fine: (gdb) tbreak main Temporary breakpoint 1 at 0x14000100c: file test.cpp, line 6. (gdb) run Starting program: C:\test-clang Temporary breakpoint 1, main () at test.cpp:6 6 std::cout << "Hello World.\n"; Remove the check entirely; a 'NOT_FOUND_ERROR' is thrown if 'main' cannot be resolved. The error is consumed in 'create_breakpoint ()' and an error message is displayed to the user. Approved-by: Kevin Buettner <kevinb@redhat.com> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
2025-02-11gdb/dwarf: rename cooked_index::m_vector to m_shardsSimon Marchi2-19/+19
I think that is clearer and helps readability. Rename a few iteration variables from "index" or "idx" to "shard". In my mental model, the "index" is the whole thing, so it's confusing to use that word when referring to shards. Change-Id: I208cb839e873c514d1f8eae250d4a16f31016148 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-11gdb/dwarf: remove cooked_index::vec_typeSimon Marchi2-8/+5
I find this typedef to be confusing. The name is a bit too generic, so it's not clear what it represents. When using the typedef for a cooked_index_shard unique pointer, I think that spelling out the vector type is not overly long. Change-Id: I99fdab5cd925c37c3835b466ce40ec9c1ec7209d Approved-By: Tom Tromey <tom@tromey.com>
2025-02-10Port GDB to Hurd x86_64.Flavio Cruz9-57/+403
This port extends the existing i686 port to support x86_64 by reusing existing code whenever it makes sense. * gdb/amd64-gnu-tdep.c: Adds logic for handling signal frames and position of amd64 registers in the different Hurd structs. The signal code is very similar to i686, except the trampoline code is adapted. * gdb/config/i386/nm-i386gnu.h: renamed to gdb/config/i386/nm-x86-gnu.h and adapt it for x86_64. * gdb/config/i386/i386gnu.mn: renamed to gdb/config/i386/nm-x86-gnu.mn and reuse it for x86_64. * gdb/configure.host: recognize gnu64 as a host. * gdb/configure.nat: recognize gnu64 host and update existing i386gnu to reuse the new shared files. * gdb/configure.tgt: recognize x86_64-*-gnu* triplet and use amd64-gnu-tdep.c. * gdb/i386-gnu-tdep.c: added i386_gnu_thread_state_reg_offset that is copied from i386-gnu-nat.c. This makes it similar to amd64. * gdb/i386-gnu-nat.c: rename it to x86-gnu-nat.c since we reuse this for i386 and amd64. Updated REG_ADDR to use one of the structures. Added VALID_REGISTER to make sure it's a register we can provide at this time (not all of them are available in amd64). FLAGS_REGISTER is either rfl or efl depending on the arch. Renamed functions and class from i386 to x86 whenever they can be reused. Tested on Hurd x86_64 and i686.
2025-02-10gdb/tui: use tui_batch_rendering moreAndrew Burgess4-2/+14
While working on the commit: commit 4f28b020a3416ac87ac12cf7ae3625a4bc178975 Date: Wed Feb 5 20:12:03 2025 +0000 gdb/tui: use wrefresh if output is not surpressed I spotted some places where tui_win_info::refresh_window() was being called when suppress_output was false. This means that there is no tui_batch_rendering in place on the call stack, and so, after that commit, we might be performing more wrefresh() calls than necessary. Before the above commit we would have been calling wnoutrefresh() and, due to the missing tui_batch_rendering, there might have been a delay before doupdate() was called. To (hopefully) make screen updates smoother, this commit adds tui_batch_rendering in a few places where it is possible that there might be multiple window updates performed, this will mean the final write to screen is deferred until the tui_batch_rendering goes out of scope. Other than possibly smother screen updates, there should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-10gdb/tui: remove unnecessary wmove call from tui_status_windowAndrew Burgess1-1/+1
I've been looking recently at when the TUI calls wnoutrefresh vs wrefresh, and the ordering of other screen update actions relative to these calls. I noticed in tui_status_window::rerender() a call to wmove() that is placed after the refresh_window() call. This surely means that the cursor is moved, but, this update is not sent to the screen. But we call wmove() at the start of tui_status_window::rerender() before anything is sent to the screen, so the final wmove() call is pointless as far as I can tell. I propose removing it. This is trivial, but removing pointless work like this slowly makes the TUI code easier to understand. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-02-10gdb: Deprecate stabs debug infoGuinevere Larsen1-0/+3
GCC has deprecated stabs generation in GCC 12 and entirely removed it in GCC 13, which was released in April 2023. At the time it was proposed that GDB deprecate stabs as well, but the decision was to support it a bit longer. With this patch, it'll be deprecated on GDB 17, and removed on GDB 18, which following the current cadence, will be released early 2026, meaning we will have supported stabs for nearly 3 years longer than GCC, which I think is reasonable. As pointed out in the previous discussion on this topic[1], there are several existing issues on the code, and none of the current maintainers knows how to fix it. Unless someone steps up to fix this before the removal on GDB 18, I don't see why we should keep this old code that breaks all conventions of modern debuginfo readers and doesn't even work, instead of being able to further advance adjacent code. Finally, deprecating and removing stabs will make a.out/dbx inferiors be essentially unsupported, as the only debuginfo GDB supports for those formats is stabs, meaning users would only have assembly-level debugging for that format. With that in mind, this commit deprecates the a.out/dbx format as well. [1] https://inbox.sourceware.org/gdb-patches/20230119174156.654402-1-tom@tromey.com/ Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31210 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-10gdb/dwarf: create multiple cooked index shards when reading .debug_namesSimon Marchi3-12/+49
New in v2: - install address map in a single shard - update test gdb.mi/mi-sym-info.exp to cope with the fact that different symbols could be returned when using --max-results When playing with the .debug_names reader, I noticed it was significantly slower than the DWARF scanner. Using a "performance" build of GDB (with optimization, no runtime sanitizer enabled, etc), I measure with the following command on a rather large debug info file (~4 GB): $ time ./gdb -q -nx --data-directory=data-directory <binary> -iex 'maint set dwarf sync on' -batch This measures the time it takes for GDB to build the cooked index (plus some startup and exit overhead). I have a version of the binary without .debug_names and a version with .debug_names added using gdb-add-index. The results are: - without .debug_names: 7.5 seconds - with .debug_names: 24 seconds This is a bit embarrassing, given that the purpose of .debug_names is to accelerate things :). The reason is that the .debug_names processing is not parallelized at all, while the DWARF scanner is heavily parallelized. The process of creating the cooked index from .debug_names is roughly in two steps: 1. scanning of .debug_names and creation of cooked index entries (see mapped_debug_names_reader::scan_all_names) 2. finalization of the index, name canonicalization and sorting of the entries (see cooked_index::set_contents). This patch grabs a low hanging fruit by creating multiple cooked index shards instead of a single one during step one. Just doing this allows the second step of the processing to be automatically parallelized, as each shard is sent to a separate thread to be finalized. With this patch, I get: - without .debug_names: 7.5 seconds - with .debug_names: 9.7 seconds Not as fast as we'd like, but it's an improvement. The process of scanning .debug_names could also be parallelized to shave off a few seconds. My profiling shows that out of those ~10 seconds of excecution, about 6 are inside scan_all_names. Assuming perfect parallelization with 8 threads, it means that at best we could shave about 5 seconds from that time, which sounds interesting. I gave it a shot, but it's a much more intrusive change, I'm not sure if I will finish it. This patch caused some regressions in gdb.mi/mi-sym-info.exp with the cc-with-debug-names board, in the test about the `--max-results` switch. It appears at this test is relying on the specific symbols returned when using `--max-results`. As far as I know, we don't guarantee which specific symbols are returned, so any of the matching symbols could be returned. The round robin method used in this patch to assign index entries to shards ends up somewhat randomizing which CU gets expanded first during the symbol search, and therefore which order they appear in the objfile's CU list, and therefore which one gets searched first. I meditated on whether keeping compunits sorted within objfiles would help make things more stable and predictable. It would somewhat, but it wouldn't remove all sources of randomness. It would still possible for a call to `expand_symtabs_matching` to stop on the first hit. Which compunit gets expanded then would still be dependent on the specific `quick_symbol_functions` internal details / implementation. Commit 5b99c5718f1c ("[gdb/testsuite] Fix various issues in gdb.mi/mi-sym-info.exp") had already started to make the test a bit more flexible in terms of which symbols it accepts, but with this patch, I think it's possible to get wildly varying results. I therefore modified the test to count the number of returned symbols, but not expect any specific symbol. Change-Id: Ifd39deb437781f72d224ec66daf6118830042941 Approved-By: Tom Tromey <tom@tromey.com>
2025-02-10gdb/dwarf: allow for cooked_index_shard::m_addrmap to be nullptrSimon Marchi3-5/+14
The following patch makes the .debug_names reader create multiple cooked index shards, only one of them having an address map. The others will have a nullptr address map. Change the code using cooked_index_shard::m_addrmap to account for the fact that it can be nullptr. Change-Id: Id05b974e661d901dd43bb5ecb3a8fcfc15abc7ed Approved-By: Tom Tromey <tom@tromey.com>
2025-02-10gdb/dwarf: write offset to parent entry for DW_IDX_parentSimon Marchi4-72/+205
New in v2: - add doc - fix computation of offset in entry pool Due to a mistake in the DWARF 5 spec, the way that GDB interprets DW_IDX_parent when generating and reading .debug_names is not correct. In Section 6.1.1.2, the parent index entry attribute is described as: Parent debugging information entry, a reference to the index entry for the parent. This is represented as the offset of the entry relative to the start of the entry pool. But in Table 6.1, DW_IDX_parent is described as: Index of name table entry for parent These two contradict each other. The former is the correct one and the latter is an unfortunate leftover from an earlier version of the proposal, according to [1]. It does make sense, because pointing to a name table entry is ambiguous, while poiting to an index entry directly is not. Unfortunately, GDB implemented pointing to a name table entry. Changes on the writer side: - For each written pool entry, remember the offset within the pool. - Change the DW_IDX_parent form to DW_FORM_data4. Using DW_FORM_udata isn't an option, because we don't know the actual value when doing the first pass of writing the pool (see next point), so we wouldn't know how many bytes to reserve, if we used a variable-size encoding. Using a fixed 4 bytes encoding would be an issue if the entry pool was larger than 4 GiB, but that seems unlikely. Note that clang uses DW_FORM_ref4 for this, but I'm not sure it is appropriate, since forms of the reference class are specified as referring "to one of the debugging information entries that describe the program". Since we're not referring to a DIE, I decided to stay with a form of the "constant" class. I think that readers will be able to understand either way. - Write a dummy 4 byte number when writing the pool, then patch those values later. This is needed because parents can appear before their children in the pool (there's no way to ensure that parents always appear before their children), so we might now know at first what value to put in. - Add a `write_uint` method to `class data_buf` to support that use case of patching a value in the middle of the data buffer. - Simplify the type of `m_name_to_value_set`, we no longer need to track the index at which a name will be written at. - Produce a new augmentation string, "GDB3", to be able to distinguish "old" and "new" indexes. It would be possible for a reader to distinguish the two semantics of DW_IDX_parent using the form. However, current versions of GDB don't do that, so they would be confused trying to read a new index. I think it is preferable to use a new augmentation string so that they will reject a new index instead. Changes on the reader side: - Track the GDB augmentation version, in addition to whether the augmentation string indicates the index was produced by GDB. - When reading index entries, maintain a "pool offset" -> "cooked index entry" mapping, to be able to find parents by pool offset. - When resolving parents, keep the existing behavior of finding parents by name table index if the augmentation string is "GDB2. Otherwise, look up parents by pool offset. This assumes that .debug_names from other producers (if/when we add support for reading them) use pool offsets for DW_IDX_parent. This at least what clang does. - Simplify augmentation string comparison a bit by using array views. Update the "Extensions to ‘.debug_names’" section of the documentation to reflect the new augmentation string version. Tested by: - manually producing executables with "GDB2" and "GDB3" .debug_names sections and reading them. - running the testsuite with the cc-with-debug-names board [1] https://lists.dwarfstd.org/pipermail/dwarf-discuss/2025-January/002618.html Change-Id: I265fa38070b86ef320e0a972c300d1d755735d8d Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-02-10gdbsupport: add gdb::make_array_view overload to create from an arraySimon Marchi1-0/+13
I think this overload will be useful for the following reasons. Consider a templated function like this: template <typename T> void func(gdb::array_view<T> view) {} Trying to pass an array to this function doesn't work, as template argument deduction fails: test.c:698:8: error: no matching function for call to ‘func(int [12])’ 698 | func (array); | ~~~~~^~~~~~~ test.c:686:6: note: candidate: ‘template<class T> void func(gdb::array_view<U>)’ 686 | void func(gdb::array_view<T> view) {} | ^~~~ test.c:686:6: note: template argument deduction/substitution failed: test.c:698:8: note: mismatched types ‘gdb::array_view<U>’ and ‘int*’ 698 | func (array); | ~~~~~^~~~~~~ Similarly, trying to compare a view with an array doesn't work. This: int array[12]; gdb::array_view<int> view; if (view == array) {} ... fails with: test.c:698:8: error: no matching function for call to ‘func(int [12])’ 698 | func (array); | ~~~~~^~~~~~~ test.c:686:6: note: candidate: ‘template<class T> void func(gdb::array_view<U>)’ 686 | void func(gdb::array_view<T> view) {} | ^~~~ test.c:686:6: note: template argument deduction/substitution failed: test.c:698:8: note: mismatched types ‘gdb::array_view<U>’ and ‘int*’ 698 | func (array); | ~~~~~^~~~~~~ With this new overload, we can do: func (gdb::make_array_view (array)); and if (view == gdb::make_array_view (array)) {} This is not ideal, I wish that omitting `gdb::make_array_view` would just work, but at least it allows creating an array view and have the element type automatically deduced from the array type. If someone knows how to make these cases "just work", I would be happy to know how. Change-Id: I6a71919d2d5a385e6826801d53f5071b470fef5f Approved-By: Tom Tromey <tom@tromey.com>
2025-02-10gdb: LoongArch: Improve the handling of atomic sequenceHui Li1-2/+4
In the current code, when using software single-step to debug atomic instruction sequence, the execution of the atomic instruction sequence may not be completed normally. Here is a test with setting a software watchpoint to execute in software single-step mode: $ cat test.c int a = 0; int main() { a = 1; return 0; } $ gcc -g test.c -o test $ gdb test .. (gdb) start .. Temporary breakpoint 1, main () at test.c:4 4 a = 1; (gdb) set can-use-hw-watchpoints 0 (gdb) n 5 return 0; (gdb) watch a Watchpoint 2: a (gdb) c Continuing. At this point, the program continues to execute and can not exit normally because it incorrectly handled the following ll/sc atomic sequence in __run_exit_handlers () from /lib64/libc.so.6 during software single-step execution. 0x00007ffff7df7a48 <+408>: ld.d $t1, $s2, 1776 0x00007ffff7df7a4c <+412>: ll.w $t0, $t1, 0 => 0x00007ffff7df7a50 <+416>: bne $t0, $zero, 20 # 0x7ffff7df7a64 <__run_exit_handlers+436> 0x00007ffff7df7a54 <+420>: or $t3, $zero, $s4 0x00007ffff7df7a58 <+424>: sc.w $t3, $t1, 0 0x00007ffff7df7a5c <+428>: beq $zero, $t3, -16 # 0x7ffff7df7a4c <__run_exit_handlers+412> 0x00007ffff7df7a60 <+432>: b 8 # 0x7ffff7df7a68 <__run_exit_handlers+440> 0x00007ffff7df7a64 <+436>: dbar 0x700 0x00007ffff7df7a68 <+440>: slli.w $t0, $t0, 0x0 The root cause of this problem is that a breakpoint was inserted in the middle of ll/sc atomic sequence during software single-step execution. The execution result of the atomic instruction sequence is disrupted, causing the program unable to complete the execution of the atomic instruction sequence normally. Further explanation, if the current pc is 0x00007ffff7df7a50, it is a conditional branch instruction, breakpoint should only be set at the jump destination address (0x00007ffff7df7a64, which is outside of the ll/sc atomic instruction sequence) and should not set at the address of pc + 4 (0x00007ffff7df7a54, which is in the middle of ll/sc atomic sequence). Modify a judgment condition in loongarch_deal_with_atomic_sequence() to ensure that breakpoints can not be inserted in the middle of ll/sc atomic sequence to address such issues. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2025-02-10gdb: fix selecting tail-call frames by nameAndrew Burgess3-2/+62
I noticed that attempting to select a tail-call frame using 'frame function NAME' wouldn't work: (gdb) bt #0 func_that_never_returns () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:49 #1 0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59 #2 0x00000000004011a5 in main () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:70 (gdb) frame function func_that_tail_calls No frame for function "func_that_tail_calls". (gdb) up #1 0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59 59 func_that_never_returns (); (gdb) disassemble Dump of assembler code for function func_that_tail_calls: 0x000000000040117a <+0>: push %rbp 0x000000000040117b <+1>: mov %rsp,%rbp 0x000000000040117e <+4>: call 0x40116c <func_that_never_returns> End of assembler dump. (gdb) The problem is that the 'function' mechanism uses get_frame_pc() and then compares the address returned with the bounds of the function we're looking for. So in this case, the bounds of func_that_tail_calls are 0x40117a to 0x401183, with 0x401183 being the first address _after_ the function. However, because func_that_tail_calls ends in a tail call, then the get_frame_pc() is 0x401183, the first address after the function. As a result, GDB fails to realise that frame #1 is inside the function we're looking for, and the lookup fails. The fix is to use get_frame_address_in_block, which will return an adjusted address, in this case, 0x401182, which is within the function bounds. Now the lookup works: (gdb) frame function func_that_tail_calls #1 0x0000000000401183 in func_that_tail_calls () at /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/frame-selection.c:59 59 func_that_never_returns (); (gdb) I've extended the gdb.base/frame-selection.exp test to cover this case.
generated by cgit v1.1 at 2025-09-20 13:30:46 +0000