aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2024-04-23gdb: move a bunch of quit-related things to event-top.{c,h}Simon Marchi51-88/+144
Move some declarations related to the "quit" machinery from defs.h to event-top.h. Most of the definitions associated to these declarations are in event-top.c. The exceptions are `quit()` and `maybe_quit()`, that are defined in utils.c. For consistency, move these two definitions to event-top.c. Include "event-top.h" in many files that use these things. Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-23gdb: change type of quit_flag to boolSimon Marchi2-5/+5
Change-Id: I7dc5189ee172e82ef5b2c4a739c011f43a84258b Approved-By: Tom Tromey <tom@tromey.com>
2024-04-23gdb: change return type of check_quit_flag to boolSimon Marchi5-12/+12
Change the return type of the check_quit_flag function to bool. Update a few related spots. Change-Id: I9d3a15d3f8651efb02c7d211f06222a592bd4184 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-23gdb: move declarations of check_quit_flag and set_quit_flag to extension.hSimon Marchi3-32/+34
Move them out of defs.h, to extension.h, since the implementations are in extension.c. Change-Id: Ie7321468bd7fecc684d70b09f72c3ee8ac75d8f4 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-23gdb: remove unused include in infrun.cSimon Marchi1-1/+1
Remove the gdbcmd.h, which is reported as unused by clangd. Add cli/cli-cmds.h instead, to get access to `cmdlist` and friends. Change-Id: Ic0c60d2f6d3618f1bd9fd80b95ffd7c33c692a04
2024-04-23gdb/dwarf2/read.c: remove pessimizing std::moveSimon Marchi1-1/+1
When building with this clang: $ c++ --version FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) I see: $ gmake CXX dwarf2/read.o /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move] std::move (thread_storage.release_parent_map ())); ^ /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: note: remove std::move call here std::move (thread_storage.release_parent_map ())); ^~~~~~~~~~~ ~ The compiler seems right, there is not need to std::move the result of `release_parent_map ()`, it's already going to be an rvalue. Remove the std::move. The issue isn't FreeBSD-specific, I see it on Linux as well when building hwith clang, I just noticed it on a FreeBSD build first. Change-Id: I7aa20a4db56c799f20d838ad08099a01653bba19 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-22gdb: don't include gdbsupport/array-view.h in defs.hSimon Marchi1-1/+0
Nothing in defs.h actually uses this. Everything that I (and the buildbot) can compile still compiles, so I guess that all users of array_view already include it one way or another. Worst case, if this causes some build failure, the fix will be one #include away. Change-Id: I981be98b0653cc18c929d85e9afd8732332efd15 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-22gdb: don't include hashtab.h in defs.hSimon Marchi4-2/+3
Nothing in defs.h actually uses this. Add some includes for some spots using things from hashtab.h. Note that if the GDB build doesn't use libxxhash, hashtab.h is included by gdbsupport/common-utils.h, so all files still see hashtab.h. It puzzled me for some time why I didn't see build failures in my build (which didn't use libxxhash) but the buildbot gave build failures (it uses libxxhash). Change-Id: I8efd68decdaf579f048941c7537cd689885caa2a Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-22gdb: move RequireLongest to gdbsupport/traits.hSimon Marchi3-4/+3
Move it out of defs.h. Change-Id: Ie1743d41a57f81667650048563e66073c72230cf Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-22gdb: move store/extract integer functions to extract-store-integer.{c,h}Simon Marchi141-327/+559
Move the declarations out of defs.h, and the implementations out of findvar.c. I opted for a new file, because this functionality of converting integers to bytes and vice-versa seems a bit to generic to live in findvar.c. Change-Id: I524858fca33901ee2150c582bac16042148d2251 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-22gdb: remove extract_long_unsigned_integerSimon Marchi2-56/+0
It is unused. Change-Id: I5d4091368c4dfc29752b12061e38f1df8353ba74 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-22gdb: move `enum compile_i_scope_types` to compile/compile.hSimon Marchi4-28/+30
Move it out of defs.h, adjust the includes here and there. Change-Id: I11901fdce55d54f5e51723e123cef154cfb1bbc5 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-22gdb: move two declarations out of defs.hSimon Marchi5-9/+10
Move declarations of initialize_progspace and initialize_inferiors to progspace.h and inferior.h, respectively. Change-Id: I62292ffda429861b9f27d8c836a56d161dfa548d Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-22gdb/testsuite: Use default gdb_expect timeout in runtoThiago Jung Bauermann1-1/+1
runto uses a hard-coded timeout of 30s in its invocation of gdb_expect. This is normally fine, but for very a slow system (e.g., an emulator) it may not be enough time for GDB to reach the intended breakpoint. gdb_expect can obtain a timeout value from user-configurable variables when it's not given one explicitly, so use that mechanism instead since the user will have already adjusted the timeout variable to account for the slow system. Approved-By: Tom Tromey <tom@tromey.com>
2024-04-22gdb: fix unknown variable typo in c-exp.yAndrew Burgess1-1/+1
Fix 'val' -> 'value' typo in c-exp.y which was breaking the build. Introduced in commit: commit e6375bc8ebbbc177c79f08e9616eb0b131229f65 Date: Wed Apr 17 16:17:33 2024 -0600 Remove some alloca uses
2024-04-21Remove a couple of VLAsTom Tromey2-2/+6
I found a couple of spots where VLAs are in use but where they can easily be removed. In one spot, adding 'const' is enough -- and is already done in similar code elsewhere in the file. In another spot, one of two arrays will be used, so making the buffer large enough for both works. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-21Remove some alloca usesTom Tromey8-64/+16
A few spots (mostly in the parsers) use alloca to ensure that a string is terminated before passing it to a printf-like function (mostly 'error'). However, this isn't needed as the "%.*s" format can be used instead. This patch makes this change. In one spot the alloca is dead code and is simply removed. Regression tested on x86-64 Fedora 38. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-19gdb: add target_debug_printf and target_debug_printf_nofuncSimon Marchi3-590/+390
Add the `target_debug_printf` and `target_debug_printf_nofunc` macros and use them when outputting debug messages depending on `targetdebug`. I opted for `target_debug_printf_nofunc` to follow the current style where the function name is already printed, along with the arguments. Modify the debug printfs in the `debug_target` methods (generated by `make-target-delegates.py`) to use `target_debug_printf_nofunc` as well. This makes the "target" debug prints integrate nicely with the other debug prints that use the "new" debug print system: [infrun] proceed: enter [infrun] follow_fork: enter [target] -> multi-thread->record_will_replay (...) [target] <- multi-thread->record_will_replay (-1, 0) = false [target] -> multi-thread->supports_multi_process (...) [target] <- multi-thread->supports_multi_process () = true [infrun] follow_fork: exit ... Change-Id: Ide3c8c1b8a30e6d4c353a29cba911c7192de29ac Approved-By: Tom Tromey <tom@tromey.com>
2024-04-19gdb: make regcache::debug_print_register return a stringSimon Marchi3-20/+21
Rename the method to `register_debug_string`. This makes it easier to introduce `target_debug_printf` in a subsequent patch. Change-Id: I5bb2d49476d17940d503e66f40762e3f1e3baabc Approved-By: Tom Tromey <tom@tromey.com>
2024-04-19gdb: make debug_target use one-linersSimon Marchi3-864/+835
Turn the debug prints in debug_target's method to be one liners. For instance, change this: gdb_printf (gdb_stdlog, "<- %s->wait (", this->beneath ()->shortname ()); gdb_puts (target_debug_print_ptid_t (arg0), gdb_stdlog); gdb_puts (", ", gdb_stdlog); gdb_puts (target_debug_print_target_waitstatus_p (arg1), gdb_stdlog); gdb_puts (", ", gdb_stdlog); gdb_puts (target_debug_print_target_wait_flags (arg2), gdb_stdlog); gdb_puts (") = ", gdb_stdlog); target_debug_print_ptid_t (result); gdb_puts ("\n", gdb_stdlog); into this: gdb_printf (gdb_stdlog, "<- %s->wait (%s, %s, %s) = %s\n", this->beneath ()->shortname (), target_debug_print_ptid_t (arg0).c_str (), target_debug_print_target_waitstatus_p (arg1).c_str (), target_debug_print_target_wait_flags (arg2).c_str (), target_debug_print_ptid_t (result).c_str ()); This makes it possible for a subsequent patch to turn this gdb_printf call into a `target_debug_printf` call. Change-Id: I808202438972fac1bba2f8ccb63e66a4fcef20c9 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-19gdb: make target debug functions return std::stringSimon Marchi5-377/+379
Change the functions in target-debug.h to return string representations in an std::string, such that they don't need to know how the printing part is done. This also helps the following patch that makes the debug prints in debug_target one-liners. Update target-delegates.c (through make-target-delegates.py) to do the printing. Add an overload of gdb_puts to avoid using `.c_str ()`. Change-Id: I55cbff1c1b03a3b24a81740e34c6ad41ac4f8453 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-19gdb: fix include for gdb_signal in target/waitstatus.hSimon Marchi3-1/+3
clangd tells me that the gdb_signals.h include in target/waitstatus.h is unused. This include was probably to give access to `enum gdb_signal`, but this is in fact defined in gdb/signals.h. Change the include to gdb/signals.h. Include gdbsupport/gdb_signals.h in some files that were relying on the transitive include. Change-Id: I6f4361b3d801394bf29abe8c1393aff110aa0ad6
2024-04-19gdb: convert target debug macros to functionsSimon Marchi1-144/+266
Convert all the macros to static functions. Some macros were unused, and now that they are functions, got flagged by the compiler, so I omitted them. No behavior change expected. Change-Id: Ia88e61d95e29a0378901c71aa50df7c37d16bebe Approved-By: Tom Tromey <tom@tromey.com>
2024-04-19gdb: add includes in target-debug.hSimon Marchi1-0/+4
Editing target-debug.h with clangd shows a bunch of errors. Add some includes to fix that (make target-debug.h include what it uses). Change-Id: I49075a171e6875fa516d6b2ce56b4a03ac7b3376
2024-04-19gdb: Document qIsAddressTagged packetGustavo Romero2-3/+44
This commit documents the qIsAddressTagged packet. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Eli Zaretskii <eliz@gnu.org> Approved-By: Eli Zaretskii <eliz@gnu.org>
2024-04-19gdb/testsuite: Add unit tests for qIsAddressTagged packetGustavo Romero1-0/+67
Add unit tests for testing qIsAddressTagged packet request creation and reply checks. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
2024-04-19gdb: Add qIsAddressTagged packetGustavo Romero1-0/+75
This commit adds a new packet, qIsAddressTagged, allowing GDB remote targets to use it to query the stub if a given address is tagged. Currently, the memory tagging address check is done via a read query, where the contents of /proc/<PID>/smaps is read and the flags are inspected for memory tagging-related flags that indicate the address is in a memory tagged region. This is not ideal, for example, for QEMU stub and other cases, such as on bare-metal, where there is no notion of an OS file like 'smaps.' Hence, the introduction of qIsAddressTagged packet allows checking if an address is tagged in an agnostic way. The is_address_tagged target hook in remote.c attempts to use the qIsAddressTagged packet first for checking if an address is tagged and if the stub does not support such a packet (reply is empty) it falls back to using the current mechanism that reads the contents of /proc/<PID>/smaps via vFile requests. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
2024-04-19gdb: Introduce is_address_tagged target hookGustavo Romero13-25/+100
This commit introduces a new target hook, target_is_address_tagged, which is used instead of the gdbarch_tagged_address_p gdbarch hook in the upper layer (printcmd.c). This change enables easy specialization of memory tagging address check per target in the future. As target_is_address_tagged continues to utilize the gdbarch_tagged_address_p hook, there is no change in behavior for all the targets that use the new target hook (i.e., the remote.c, aarch64-linux-nat.c, and corelow.c targets). Just the gdbarch_tagged_address_p signature is changed for convenience, since target_is_address_tagged takes the address to be checked as a CORE_ADDR type. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
2024-04-19gdb: Use passed gdbarch instead of calling current_inferiorGustavo Romero1-1/+1
In do_examine function, use passed gdbarch when checking if an address is tagged instead of calling current_inferior()->arch() to make the code more localized and help modularity by not calling a current_* function, which disguises the use of a global state/variable. There is no change in the code behavior. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Suggested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
2024-04-19gdb: aarch64: Remove MTE address checking from memtag_matches_pGustavo Romero1-4/+0
This commit removes aarch64_linux_tagged_address_p from aarch64_linux_memtag_matches_p. aarch64_linux_tagged_address_p checks if an address is tagged (MTE) or not. The check is redundant because aarch64_linux_memtag_matches_p is always called from the upper layers (i.e. from printcmd.c via gdbarch hook gdbarch_memtag_matches_p) after either gdbarch_tagged_address_p (that already points to aarch64_linux_tagged_address_p) has been called or after should_validate_memtags (that calls gdbarch_tagged_address_p at the end) has been called, so the address is already checked. Hence: a) in print_command_1, gdbarch_memtag_matches_p is called only after should_validate_memtags is called, which checks the address at its end; b) in memory_tag_check_command, gdbarch_memtag_matches_p is called only after gdbarch_tagged_address_p is called directly. Also, because after this change the address checking only happens at the upper layer it now allows the address checking to be specialized easily per target, via a target hook. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
2024-04-19gdb: aarch64: Move MTE address check out of set_memtagGustavo Romero2-9/+5
Remove check in parse_set_allocation_tag_input as it is redundant: currently the check happens at the end of parse_set_allocation_tag_input and also in set_memtag (called after parse_set_allocation_tag_input). After it, move MTE address check out of set_memtag and add this check to the upper layer, before set_memtag is called. This is a preparation for using a target hook instead of a gdbarch hook on MTE address checks. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com>
2024-04-19gdb: aarch64: Remove MTE address checking from get_memtagGustavo Romero1-4/+0
This commit removes aarch64_linux_tagged_address_p from aarch64_linux_get_memtag. aarch64_linux_tagged_address_p checks if an address is tagged (MTE) or not. The check is redundant because aarch64_linux_get_memtag is always called from the upper layers (i.e. from printcmd.c via gdbarch hook gdbarch_get_memtag) after either gdbarch_tagged_address_p (that already points to aarch64_linux_tagged_address_p) has been called or after should_validate_memtags (that calls gdbarch_tagged_address_p at the end) has been called, so the address is already checked. Hence: a) in print_command_1, aarch64_linux_get_memtag (via gdbarch_get_memtag hook) is called but only after should_validate_memtags, which calls gdbarch_tagged_address_p; b) in do_examine, aarch64_linux_get_memtag is also called only after gdbarch_tagged_address_p is directly called; c) in memory_tag_check_command, gdbarch_get_memtag is called -- tags matching or not -- after the initial check via direct call to gdbarch_tagged_address_p; d) in memory_tag_print_tag_command, address is checked directly via gdbarch_tagged_address_p before gdbarch_get_memtag is called. Also, because after this change the address checking only happens at the upper layer it now allows the address checking to be specialized easily per target, via a target hook. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
2024-04-18[gdb/testsuite] Use find_gnatmake instead of gdb_find_gnatmakeTom de Vries2-1/+16
On SLE-11, with an older dejagnu version, I ran into: ... Running gdb.ada/mi_prot.exp ... UNRESOLVED: gdb.ada/mi_prot.exp: \ testcase aborted due to invalid command name: gdb_find_gnatmake ERROR: tcl error sourcing gdb.ada/mi_prot.exp. ERROR: invalid command name "gdb_find_gnatmake" while executing "::gdb_tcl_unknown gdb_find_gnatmake" ("uplevel" body line 1) invoked from within "uplevel 1 ::gdb_tcl_unknown $args" (procedure "::unknown" line 5) invoked from within "gdb_find_gnatmake" (procedure "gnatmake_version_at_least" line 2) invoked from within ... Proc gdb_find_gnatmake is actually a backup for find_gnatmake: ... if {[info procs find_gnatmake] == ""} { rename gdb_find_gnatmake find_gnatmake ... so gnatmake_version_at_least should use find_gnatmake instead. For a recent dejagnu with find_gnatmake, gdb_find_gnatmake is kept, and we don't run into this error. For an older dejagnu without find_gnatmake, gdb_find_gnatmake is renamed to find_gnatmake, and we do run into the error. It's confusing that we're using the gdb_ prefix for gdb_find_gnatmake, it seems something legitimate to use. Maybe we should use future_ or gdb_future_ prefix instead to make this more clear, but I've left that alone for now. Fix this by: - triggering the same error with a recent dejagnu by removing gdb_find_gnatmake unless used (and likewise for other procs in future.exp), and - using find_gnatmake in gnatmake_version_at_least. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/31647 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647
2024-04-18[gdb/testsuite] Use allocator_may_return_null=1 in two test-casesTom de Vries3-6/+33
Simon reported [1] that recent commit 06e967dbc9b ("[gdb/python] Throw MemoryError in inferior.read_memory if malloc fails") introduced AddressSanitizer allocation-size-too-big errors in the two test-cases affected by this commit. Fix this by suppressing the error in the two test-cases using allocator_may_return_null=1. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> [1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html
2024-04-18gdbsupport: constify some return values in print-utils.{h,cc}Simon Marchi2-2/+2
There is no reason the callers of these functions need to change the returned string, so change the `char *` return types to `const char *`. Update a few callers to also use `const char *`. Change-Id: I94adff574d5e1b326e8cc688cf1817a15b408b96 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-18Add DW_TAG_compile_unit DIE to Dummy CUsWill Hawkins1-0/+1
Dummy CUs help detect errors and are very helpful. However, the DWARF spec seems to indicate the CUs need a DW_TAG_compile_unit in addition to the header. This patch adds that. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31650 Signed-off-by: Will Hawkins <hawkinsw@obs.cr> Approved-By: Tom de Vries <tdevries@suse.de> Tested-By: Tom de Vries <tdevries@suse.de>
2024-04-17Remove a copy from c-exp.y:parse_numberTom Tromey1-18/+13
parse_number copies its input string, but there is no need to do this. This patch removes the copy. Regression tested on x86-64 Fedora 38. Reviewed-by: Keith Seitz <keiths@redhat.com>
2024-04-17gdb/Windows: Fix detach while runningPedro Alves3-8/+267
While testing a WIP Cygwin GDB that supports non-stop, I noticed that gdb.threads/attach-non-stop.exp exposes that this: (gdb) attach PID& ... (gdb) detach ... hangs. And it turns out that it hangs in all-stop as well. This commits fixes that. After "attach &", the target is set running, we've called ContinueDebugEvent and the process_thread thread is waiting for WaitForDebugEvent events. It is the equivalent of "attach; c&". In windows_nat_target::detach, the first thing we do is unconditionally call windows_continue (for ContinueDebugEvent), which blocks in do_synchronously, until the process_thread sees an event out of WaitForDebugEvent. Unless the inferior happens to run into a breakpoint, etc., then this hangs indefinitely. If we've already called ContinueDebugEvent earlier, then we shouldn't be calling it again in ::detach. Still in windows_nat_target::detach, we have an interesting issue that ends up being the bulk of the patch -- only the process_thread thread can call DebugActiveProcessStop, but if it is blocked in WaitForDebugEvent, we need to somehow force it to break out of it. The only way to do that, is to force the inferior to do something that causes WaitForDebugEvent to return some event. This patch uses CreateRemoteThread to do it, which results in WaitForDebugEvent reporting CREATE_THREAD_DEBUG_EVENT. We then terminate the injected thread before it has a chance to run any userspace code. Note that Win32 functions like DebugBreakProcess and GenerateConsoleCtrlEvent would also inject a new thread in the inferior. I first used DebugBreakProcess, but that is actually more complicated to use, because we'd have to be sure to consume the breakpoint event before detaching, otherwise the inferior would likely die due a breakpoint exception being raised with no debugger around to intercept it. See the new break_out_process_thread method. So the fix has two parts: - Keep track of whether we've called ContinueDebugEvent and the process_thread thread is waiting for events, or whether WaitForDebugEvent already returned an event. - In windows_nat_target::detach, if the process_thread thread is waiting for events, unblock out of its WaitForDebugEvent, before proceeding with the actual detach. New test included. Passes cleanly on GNU/Linux native and gdbserver, and also passes cleanly on Cygwin and MinGW, with the fix. Before the fix, it would hang and fail with a timeout. Tested-By: Hannes Domani <ssbssa@yahoo.de> Reviewed-By: Tom Tromey <tom@tromey.com> Change-Id: Ifb91c58c08af1a9bcbafecedc93dfce001040905
2024-04-17gdb+gdbserver/Linux: Remove USE_SIGTRAP_SIGINFO fallbackPedro Alves2-58/+6
It's been over 9 years (since commit faf09f0119da) since Linux GDB and GDBserver started relying on SIGTRAP si_code to tell whether a breakpoint triggered, which is important for non-stop mode. When that then-new code was added, I had left the then-old code as fallback, in case some architectured still needed it. Given AFAIK there haven't been complaints since, this commit finally removes the fallback code, along with USE_SIGTRAP_SIGINFO. Change-Id: I140a5333a9fe70e90dbd186aca1f081549b2e63d
2024-04-17Use section name in DWARF error messageTom Tromey1-2/+3
A bug points out that a certain error message in read_str_index uses a hard-coded section name. This patch changes it to use dwarf2_section_info::get_name instead, like the other errors in the function. No test because it didn't seem worthwhile. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31639 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-04-17gdbsupport, gdbserver, gdb: use -Wno-vla-cxx-extensionSimon Marchi1-0/+1
When building with clang 18, I see: CXX aarch64-linux-tdep.o /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension] 1299 | gdb_byte za_zeroed[za_bytes]; | ^~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: note: read of non-const variable 'za_bytes' is not allowed in a constant expression /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1282:10: note: declared here 1282 | size_t za_bytes = std::pow (sve_vl_from_vg (svg), 2); | ^ Since we are using VLAs right now, that warning doesn't make sense for us. add `-Wno-vla-cxx-extension` to the list of warning flags we try to enable. If we ever choose to disallow VLAs, we can remove that flag. Change-Id: Ie41feafc50c343f6e75333d4f836ce32fbeb6d8c
2024-04-17Fix include guard typoMatt Wozniski1-1/+1
Signed-off-by: Matt Wozniski <godlygeek@gmail.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31645 Approved-By: Tom Tromey <tom@tromey.com>
2024-04-17gdb/record: minor clean, remove some unneeded argumentsAndrew Burgess3-6/+37
I spotted that the two functions: record_full_open_1 record_full_core_open_1 both took two arguments, neither of which are used. I stumbled onto this while reviewing how filename_completer is used. The 'record full restore' command uses filename_completer and invokes the cmd_record_full_restore function. The cmd_record_full_restore function calls core_file_command and then record_full_open, which then calls one of the above functions. As 'record full restore' takes a filename, this is passed to cmd_record_full_restore, which forwards the filename to both core_file_command and record_full_open. However, record_full_open never actually uses the filename that is passed in. The record_full_open function is also used for 'target record-full'. I propose that record_full_open should no longer expect to see any user supplied arguments passed in (it doesn't use any). In fact, I've added a check that if we do get any user supplied arguments we'll throw an error. Now that we know record_full_open isn't being passed any user arguments we can stop passing the arguments to record_full_open_1 and record_full_core_open_1, this will make no user visible difference as these arguments were not used. It is possible that a user was previously doing: (gdb) target record-full blah blah blah And this previously would work fine, the 'blah blah blah' was ignored. Now this will give an error. Other than this case there should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-04-17gdb/record: add an assert in cmd_record_startAndrew Burgess1-1/+6
The 'record' command is both a prefix command AND an alias for 'target record-full'. As it is a prefix command, if a user types: (gdb) record blah Then GDB will look for, and try to invoke the 'blah' sub-command. This will either succeed (if blah is found) or throw an error (if blah is not found). As such, the only way to invoke the 'record' command is like: (gdb) record It is impossible to pass arguments to the 'record' command. As we know this is true then we can assert this in cmd_record_start. I added this assert because initially I was going to try forwarding ARGS from cmd_record_start to the 'target record-full' command, but then I realised passing arguments to 'record' was impossible. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-04-17gdb/record: remove unnecessary use of filename_completerAndrew Burgess1-2/+0
Spotted that the 'record' command has its completer set to filename_completer. The problem is that 'record' is a prefix command, as such, its completer is hard-coded to complete on sub-commands. The attempt to use filename_completer is irrelevant. The 'record' command is itself a command though, that is, a user can do this: (gdb) record which is really just an alias for: (gdb) target record-full Nowhere does cmd_record_start (which is called when 'record' is used) expect a filename, and 'target record-full' doesn't expect a filename either. So lets just drop the line which sets filename_completer as the completer for 'record'. Approved-By: Tom Tromey <tom@tromey.com>
2024-04-17[gdb/testsuite] Require DW_LNE_end_sequenceTom de Vries4-0/+43
The dwarf standard requires that every line number program sequence ends with a DW_LNE_end_sequence instruction. Enforce this in the dwarf assembler for the last sequence in a line number program (we have no means to enforce this for earlier sequences), and fix a few test-case that don't have it. Tested on aarch64-linux. PR testsuite/31618 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31618
2024-04-17[gdb/testsuite] Fix end_sequence addressesTom de Vries10-11/+16
I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: ... 00000000004102c4 <end_of_sequence>: 4102c4: 52800000 mov w0, #0x0 // #0 4102c8: 9100c3ff add sp, sp, #0x30 4102cc: d65f03c0 ret ... is not described by the line table: ... File name Line number Starting address View Stmt ... map-to-same-line.c 54 0x4102ac x map-to-same-line.c - 0x4102c4 ... Fix this by ending the line table at $main_end. Likewise in a few other test-cases, found using: ... $ find gdb/testsuite/ -type f \ | xargs grep -B1 DW_LNE_end_sequence \ | grep set_address \ | egrep -v "_end|_len" ... Tested on aarch64-linux.
2024-04-17[gdb/testsuite] Require address update for DW_LNS_copyTom de Vries7-0/+16
No address update before a DW_LNS_copy might mean an incorrect dwarf assembly test-case. Try to catch such incorrect dwarf assembly test-cases by: - requiring an explicit address update for each DW_LNS_copy, and - handling the cases where an update is indeed not needed, by adding "DW_LNS_advance_pc 0". Tested on aarch64-linux.
2024-04-17[gdb/testsuite] Require address update for DW_LNE_end_sequenceTom de Vries11-27/+32
With test-case gdb.dwarf2/dw2-epilogue-begin.exp, we have an end_sequence entry with the same address as the line entry before it: ... File name Line number Starting address View Stmt dw2-epilogue-begin.c 44 0x4101e8 x dw2-epilogue-begin.c 47 0x4101ec x dw2-epilogue-begin.c - 0x4101ec ... and consequently the line entry is removed by gdb: ... INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PRO EPI 0 20 0x00000000004101a8 0x00000000004101a8 Y Y Y 1 27 0x00000000004101b0 0x00000000004101b0 Y 2 32 0x00000000004101b8 0x00000000004101b8 Y Y 3 34 0x00000000004101c0 0x00000000004101c0 Y Y 4 35 0x00000000004101c8 0x00000000004101c8 Y 5 40 0x00000000004101d4 0x00000000004101d4 Y Y 6 44 0x00000000004101e8 0x00000000004101e8 Y 7 END 0x00000000004101ec 0x00000000004101ec Y ... This is a common mistake in dwarf assembly test-cases. Fix this by: - requiring an address update for each DW_LNE_end_sequence, and - fixing the test-cases where that triggers an error. I also encountered the error in test-case gdb.dwarf2/dw2-bad-elf.exp, and in this case I worked around it using "DW_LNS_advance_pc 0". Tested on aarch64-linux. PR testsuite/31592 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31592
2024-04-17Fix max-depth test case for AIX.Aditya Vidyadhar Kamath1-0/+9
In AIX, if in the main program the global variables are unused then the linker optimises these variables and the dwarf will not have proper address to the same. Hence we cannot access these variables. This patch is a fix to the same so that all the test case of max-depth can passs in AIX as well.
generated by cgit v1.1 at 2024-11-21 22:18:49 +0000