aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2024-05-14Remove fflush call from tui_refresh_cmd_winTom Tromey1-5/+0
tui_refresh_cmd_win calls fflush, but there's a comment explaining that the reason for the call is unknown. This patch removes the call. I don't think it can be useful, since gdb doesn't generally use stdout in this way -- only through ui_file.
2024-05-14gdb/doc: don't delete *.pod files too earlyAndrew Burgess1-4/+2
When doing 'make -C gdb/doc man' to build the man pages, I noticed that the outputs were being rebuilt each time the make command was rerun, even when the input files hadn't changed. This was caused by this commit: commit 824083f34c222aa7419e2ea58e82d6f230d5f531 Date: Fri Apr 12 17:47:20 2024 +0100 gdb/doc: use silent-rules.mk in the Makefile Which split the generation of the .pod file from the actual creation of the man page file. Prior to this split it was OK to delete the .pod file at the end of the recipe, the rule depending on the .texi input file, and output was the .1 or .5 man page file. Now however, with the split, the man page creation depends on the .pod file, if we delete this after creating the .1 or .5 man page file then the next time we run 'make' the .pod file is missing and is regenerated, which in turn triggers the regeneration of the man page file. Fix this by leaving the .pod file around, and only cleaning up these files in the 'mostlyclean' target. Which leads to a second problem, the POD_FILE_TMPS is not created correctly, so we don't actually clean up the .pod files! This too is fixed in this commit. After this commit running 'make -C gdb/doc man' will build the manual pages the first time, and each subsequent run will do nothing. Running 'make -C gdb/doc mostlyclean' will now delete the .pod files. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-14gdb/testsuite: remove unnecessary -Wl,-soname,NAME build flagsAndrew Burgess4-14/+8
While working on another patch I needed to pass -Wl,-soname,NAME as a compiler flag. I initially looked for other tests that did this, and found a few examples, so I copied what they did. But when I checked the gdb.log file I noticed that we were actually getting -Wl,-soname passed twice. I tracked the repeated option to 'proc gdb_compile_shlib_1' in lib/gdb.exp. It turns out that we always add -Wl,-soname when compiling a shared library. Here's an example of a build command from gdb.base/prelink.exp: builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \ /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink-lib.c.o \ -fdiagnostics-color=never -shared -g \ -Wl,-soname,prelink.so -Wl,-soname,prelink.so -lm \ -o /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink.so Notice that '-Wl,-soname,prelink.so' is repeated. I believe that all of the places where tests add '-Wl,-soname,NAME' as a build option, are unnecessary. In this commit I propose we remove them all. As part of this change I've switched from calling gdb_compile_shlib directly, to instead call build_executable and adding the 'shlib' flag. I've tested with gcc and clang and see no changes in the test results after this commit. All the compile commands still have -Wl,-soname added, but now it's only added once, from within lib/gdb.exp. There should be no change in what is tested after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-14Adjust C++ destructor type testsJason Merrill1-3/+3
In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge" parameter from destructors of classes with no virtual bases; Linaro's CI informed me that the gdb testsuite needs to be adjusted to match. Teested against GCC 13.2 and GCC 15 trunk. Approved-by: Kevin Buettner <kevinb@redhat.com>
2024-05-14Fix Segmentation Fault in AIX during multi process debugging.Aditya Vidyadhar Kamath1-1/+2
Due to the recent commit in aix-thread.c, we see a segmentation fault in AIX while debugging multiple process involving multiple threads. One example is a thread that can fork. The GDB output in AIX for the same is Reading symbols from //gdb_tests/multi-thread-fork... (gdb) set detach-on-fork off (gdb) r Starting program: /gdb_tests/multi-thread-fork [New Thread 258 (tid 67110997)] [New Thread 515 (tid 127404289)] [New inferior 2 (process 16580940)] Hello from Parent! [process 16580940 exited] [New inferior 3 (process 14549318)] Hello from Parent! [process 14549318 exited] Fatal signal: Segmentation fault ----- Backtrace ----- This is because in sync_threadlists () in aix-thread.c there when we delete threads in unknown state we iterate through all the threads. When we have one or more threads with the same user thread ID but of different process then we delete a wrong thread. Since we just check only the pdtid in in_queue_threads.count (priv->pdtid) == 0 this happened. This patch is a fix for the same. The output after we apply this patch is: Reading symbols from //gdb_tests/multi-thread-fork... (gdb) set detach-on-fork off (gdb) r Starting program: /gdb_tests/multi-thread-fork [New Thread 258 (tid 75565441)] [New Thread 515 (tid 63244397)] [New inferior 2 (process 10813892)] Hello from Parent! [New inferior 3 (process 19005888)] Hello from Parent! Thread 1.1 received signal SIGINT, Interrupt. 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) (gdb) info threads Id Target Id Frame * 1.1 Thread 1 (tid 66062355) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) 1.2 Thread 258 (tid 75565441) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 1.3 Thread 515 (tid 63244397) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 2.1 Thread 515 (tid 32113089) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) 3.1 Thread 258 (tid 64489699) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) (gdb) q A debugging session is active.
2024-05-11[gdb/testsuite] Fix Wreturn-mismatch in gdb.base/list-dot-nodebug.expTom de Vries1-1/+1
When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide container, I run into: ... temp/$pid/static-libc.c: In function 'main': temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function returning void [-Wreturn-mismatch] 2 | void main (void) { return 0; } | ^ ... UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link ... Fix this by changing the return type to int. Tested on x86_64-linux.
2024-05-10Change gdbarch_inner_than to return boolTom Tromey7-13/+13
A recent patch from Andrew pointed out that gdbarch_inner_than returns 'int', while it should really return 'bool'. Approved-By: Pedro Alves <pedro@palves.net>
2024-05-10Remove tui_refresh_allTom Tromey3-14/+5
This removes tui_refresh_all. There is only a single caller, tui_refresh_all_win, so inlining the code there simplifies gdb at no cost. Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-10Add symbol, line, and location to DAP disassemble resultTom Tromey3-7/+209
The DAP spec allows a number of attributes on the resulting instructions that gdb currently does not emit. A user requested some of these, so this patch adds the 'symbol', 'line', and 'location' attributes. While the spec lets the implementation omit 'location' in some cases, it was simpler in the code to just always emit it, as then no extra tracking was needed.
2024-05-10Implement tp_richcompare for gdb.BlockTom Tromey1-1/+23
I noticed that two gdb.Block objects will never compare as equal with '=='. This patch fixes the problem by implementing tp_richcompare, as was done for gdb.Frame.
2024-05-10Simplify DAP make_source callersTom Tromey3-7/+8
A couple callers of make_source call basename by hand. Rather than add another caller like this, I thought it would be better to put this ability into make_source itself.
2024-05-10Remove FIXME from DAPTom Tromey1-1/+0
This patch removes one of the few DAP "FIXME" comments. This particular comment is already covered by PR dap/31036.
2024-05-10Pass stream to remote_console_outputTom Tromey1-8/+12
I noticed that remote_target::rcmd did not pass its ui_file argument down to remote_console_output. This patch fixes this oversight. Tested-By: Ciaran Woodward <ciaranwoodward@xmos.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-10gdb: add gdbarch_stack_grows_down functionAndrew Burgess3-6/+30
In another patch I'm working on I needed to ask: does the stack grow down, or grow up? Looking around I found in infcall.c some code where we needed to ask the same question, what we do there is ask: gdbarch_inner_than (gdbarch, 1, 2) which should do the job. However, I don't particularly like copying this, it feels like we're asking something slightly different that just happens to align with the question we're actually asking. I propose adding a new function `gdbarch_stack_grows_down`. This is not going to be a gdbarch method that can be overridden, instead, this will just call the gdbarch_inner_than function. We already have some gdbarch methods like this, checkout arch-utils.c for examples. I think it's now clearer what we're actually doing. A new self-test ensures that all architectures have a stack that either grows down, or grows up. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-10gdb sim testing, set gdb_protocol to "sim"Pedro Alves1-0/+4
Bernd reported that when testing with riscv-unknown-elf target using the simulator, before commit c7a2ee649115 ("gdb_is_target_native -> gdb_protocol_is_native"), he had: PASS: gdb.base/load-command.exp: probe for target native PASS: gdb.base/load-command.exp: check initial value of the_variable PASS: gdb.base/load-command.exp: manually change the_variable PASS: gdb.base/load-command.exp: check manually changed value of the_variable PASS: gdb.base/load-command.exp: reload: re-load binary PASS: gdb.base/load-command.exp: reload: check initial value of the_variable and now: UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command The problem is that the sim board/config isn't setting gdb_protocol anywhere, so gdb_protocol_is_native returns true. This commit fixes it by making gdb/testsuite/config/sim.exp set gdb_protocol to "sim". Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Tested-by: Bernd Edlinger <bernd.edlinger@hotmail.de> Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a
2024-05-10[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust (fixup)Tom de Vries1-9/+17
In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust") I added this code in unwind_infopy_add_saved_register: ... if (value->optimized_out () || !value->entirely_available ()) ... which may throw c++ exceptions. This needs to be caught and transformed into a python exception. Fix this by using GDB_PY_HANDLE_EXCEPTION. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust")
2024-05-09Fix typo in gdb/README.Eli Zaretskii1-1/+1
Patch from Tiezhu Yang <yangtiezhu@loongson.cn>.
2024-05-09gdb: convert address_in_mem_range to mem_range::containsAndrew Burgess4-12/+10
Replace the global function address_in_mem_range with the member function mem_range::contains. The implementation of the function doesn't change. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-09gdb: add a new build_id_equal functionAndrew Burgess3-6/+29
Add two versions of a new function build_id_equal which can be used to compare build-ids, then make use of these functions in GDB. It seems better to have a specific function for the task of comparing build-ids rather than having a length check followed by a memcmp call. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-08gdb/doc: use silent-rules.mk in the MakefileAndrew Burgess2-85/+90
Make use of silent-rules.mk when building the GDB docs. During review it was requested that there be more specific rules than just reusing the general 'GEN' rule everywhere in the doc/ directory, so I've added: ECHO_DVIPS = @echo " DVIPS $@"; ECHO_TEX = @echo " TEX $@"; ECHO_PDFTEX = @echo " PDFTEX $@"; ECHO_TEXI2DVI = @echo " TEXI2DVI $@"; ECHO_MAKEHTML = @echo " MAKEHTML $@"; ECHO_TEXI2POD = @echo " TEXI2POD $@"; ECHO_TEXI2MAN = @echo " TEXI2MAN $@"; ECHO_MAKEINFO = @echo " MAKEINFO $@"; Then I've made use of these new silent rules and added lots of uses of SILENT to reduce additional clutter. As the man page generation is done in two phases, first the creation of a .pod file, then the creation of the final man page file, I've restructured the man page rules. Previously we had one rule for each of the 5 man pages. I now have one general rule that will generate all of the 5 .pod files, then I have two rules that convert the .pod files into the final man pages. I needed two rules for the man page generation as some man pages match %.1 and some match %.5. I could combine these by using the GNU Make .SECONDARYEXPANSION extension, but I think having two rules like this is probably clearer, and the duplication is minimal. Cleaning up the temporary .pod files is now moved into the 'mostlyclean' target rather than being done as soon as the man page is created. I've added a new SILENT_Q_FLAG to silent-rules.mk, this is like SILENT_FLAG, but is set to '-q' when in silent mode, this can be used with the 'dvips' and 'texi2dvi' commands, both of which use '-q' to mean: only report errors. As with the rest of the GDB makefiles, I've only converted the "generation" rules to use silent-rules.mk, the install / uninstall rules are left unchanged. When looking at the 'diststuff' target, which generates the info and man pages, I noticed the recipe for this rule just deleted a temporary file. As that temporary file is already cleaned up as part of the 'clean' rule I've removed the deletion from the 'diststuff' target. There are still a few "generation" targets that produce output, there seems to be no flag to silence the 'tex' and 'pdftex' commands which some recipes use, I've not worried about these for now, e.g. the refcard.dvi and refcard.pdf targets still produce some output. Luckily, when doing a 'make all' in the gdb/ directory, we only build the info docs by default, and those rules are now nice and silent, so a complete GDB build is now looking nice and quiet by default. While working on this patch I noticed that 'make -j all-doc' doesn't work (reliably), this is a preexisting bug in the way that dvi/pdf targets are generated. For example gdb.dvi and gdb.pdf both use the texi2dvi tool, which relies on temporary files to hold state. If both these rules run in parallel then one (or both) of the recipes will fail. Luckily, the default docs target (all), which is what gets run when we do 'make all' in the gdb/ directory, doesn't build the dvi and pdf targets, so we're OK in that case. I've not tried to fix this problem in this commit as it already existed, and I don't want to do too much in one commit. I mention it only because I ran into this issue while testing this commit.
2024-05-08gdb: Change "list ." command's error when no debuginfo is availableGuinevere Larsen6-13/+155
Currently, when a user tries to list the current location, there are 2 different error messages that can happen, either: (gdb) list . No symbol table is loaded. Use the "file" command. or (gdb) list . No debug information available to print source lines. The difference here is if gdb can find any symtabs at all or not, which is not something too important for end-users - and isn't informative at all. This commit changes it so that the error always says that there isn't debug information available, with these two variants: (gdb) list . Insufficient debug info for showing source lines at current PC (0x55555555511d). or (gdb) list . Insufficient debug info for showing source lines at default location. The difference now is if the inferior has started already, which is controlled by the user and may be useful. Unfortunately, it isn't as easy to differentiate if the symtab found for other list parameters is correct, so other invocations, such as "list +" still retain their original error message. Co-Authored-By: Simon Marchi <simark@simark.ca> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-08gdb: more filename stylingAndrew Burgess2-10/+16
I spotted a few places in solib.c and build-id.c where we could apply file name styling. Other than the extra styling, there should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-08[gdb/testsuite] Add gdb.tui/reread.expTom de Vries1-0/+39
Add a regression test for commit d68f983f88c ("Fix heap-use-after-free because all_objfiles_removed triggers tui_display_main"). When building with address sanitizer, and reverting the commit it triggers the heap-use-after-free. Tested on aarch64-linux. PR symtab/31697 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697
2024-05-08Fix AIX thread exit events not being reported and UI to show kernel thread ID.Aditya Vidyadhar Kamath2-170/+78
In AIX when a thread exits we were not showing that a thread exit event happened and GDB continued to keep the terminated threads. If we have terminated threads then the UI on info threads command will look like (gdb) info threads Id Target Id Frame * 1 Thread 1 (tid 26607979, running) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o) 2 Thread 258 (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.) If we see the frame is not getting displayed correctly. The reason for the same is that in AIX we were not managing thread states. In particular we do not know when a thread terminates. The reason being in sync_threadlists () the pbuf and gbuf lists remain the same though certain threads exit. This patch is a fix to the same. Also certain UI is changed. On a new thread born and exit the UI in AIX will be similar to Linux with both user and kernel thread information. [New Thread 258 (tid 32178533)] [New Thread 515 (tid 30343651)] [New Thread 772 (tid 33554909)] [New Thread 1029 (tid 24969489)] [New Thread 1286 (tid 18153945)] [New Thread 1543 (tid 30736739)] [Thread 258 (tid 32178533) exited] [Thread 515 (tid 30343651) exited] [Thread 772 (tid 33554909) exited] [Thread 1029 (tid 24969489) exited] [Thread 1286 (tid 18153945) exited] [Thread 1543 (tid 30736739) exited] and info threads will look like (gdb) info threads Id Target Id Frame * 1 Thread 1 (tid 31326579) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) Also a small change to testcase gdb.threads/thread_events.exp to make sure this test runs on AIX as well.
2024-05-08[gdb/python] Make gdb.UnwindInfo.add_saved_register more robustTom de Vries1-0/+12
On arm-linux, until commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register from non-FreeBSD target descriptions") I ran into: ... FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: \ backtrace when the unwind is broken at frame 5 ... What happens is the following: - the TestUnwinder from inline-frame-cycle-unwind.py calls gdb.UnwindInfo.add_saved_register with reg == tpidruro and value "<unavailable>", - pyuw_sniffer calls value->contents ().data () to access the value of the register, which throws an UNAVAILABLE_ERROR, - this causes the TestUnwinder unwinder to fail, after which another unwinder succeeds and returns the correct frame, and - the test-case fails because it's counting on the TestUnwinder to succeed and return an incorrect frame. Fix this by checking for !value::entirely_available as well as valued::optimized_out in unwind_infopy_add_saved_register. Tested on x86_64-linux and arm-linux. Approved-By: Andrew Burgess <aburgess@redhat.com> PR python/31437 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31437
2024-05-07Fix heap-use-after-free because all_objfiles_removed triggers tui_display_mainHannes Domani1-11/+2
Since gdb-10 there is a heap-use-after free happening if starting the target in TUI triggers a re-reading of symbols. It can be reproduced with: $ gdb -q -batch a.out -ex "tui enable" -ex "shell touch a.out" -ex start ==28392== Invalid read of size 1 ==28392== at 0x79E97E: lookup_global_or_static_symbol(char const*, block_enum, objfile*, domain_enum) (symtab.h:503) ==28392== by 0x79F859: lookup_global_symbol(char const*, block const*, domain_enum) (symtab.c:2641) ==28392== by 0x79F8E9: language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const (symtab.c:2473) ==28392== by 0x7A66EE: lookup_symbol_aux(char const*, symbol_name_match_type, block const*, domain_enum, language, field_of_this_result*) (symtab.c:2150) ==28392== by 0x7A68C9: lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) (symtab.c:1958) ==28392== by 0x7A6A25: lookup_symbol(char const*, block const*, domain_enum, field_of_this_result*) (symtab.c:1970) ==28392== by 0x77120F: select_source_symtab() (source.c:319) ==28392== by 0x7EE2D5: tui_get_begin_asm_address(gdbarch**, unsigned long*) (tui-disasm.c:401) ==28392== by 0x807558: tui_display_main() (tui-winsource.c:55) ==28392== by 0x7937B5: clear_symtab_users(enum_flags<symfile_add_flag>) (functional:2464) ==28392== by 0x794F40: reread_symbols(int) (symfile.c:2690) ==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398) ==28392== Address 0x4e67848 is 3,864 bytes inside a block of size 4,064 free'd ==28392== at 0x4A0A430: free (vg_replace_malloc.c:446) ==28392== by 0x936B63: _obstack_free (obstack.c:280) ==28392== by 0x79541E: reread_symbols(int) (symfile.c:2579) ==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398) ==28392== by 0x4FFC45: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:2735) ==28392== by 0x7DAB50: execute_command(char const*, int) (top.c:575) ==28392== by 0x5D2B43: command_handler(char const*) (event-top.c:552) ==28392== by 0x5D3A50: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:788) ==28392== by 0x5D1F4B: gdb_rl_callback_handler(char*) (event-top.c:259) ==28392== by 0x857B3F: rl_callback_read_char (callback.c:290) ==28392== by 0x5D215D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:195) ==28392== by 0x5D232F: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:234) The problem is that tui_display_main is called by the all_objfiles_removed hook, which tries to access the symbol cache. This symbol cache is actually stale at this point, and would have been flushed immediately afterwards by that same all_objfiles_removed hook. It's not possible to tell the hook to call the observers in a specific order, but in this case the tui_all_objfiles_removed observer is actually not needed, since it only calls tui_display_main, and a 'main' can only be found if objfiles are added, not removed. So the fix is to simply remove the tui_all_objfiles_removed observer. The clearing of the source window (if symbols were removed by e.g. 'file' without arguments) still works, since this is done by the tui_before_prompt observer. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-07gdb/arch: assert that X86_XSTATE_MPX is not set for x32Andrew Burgess1-2/+6
While rebasing this series[1] past this commit: commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a Date: Wed Mar 20 04:13:18 2024 -0700 gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 I worried that there could be other paths that might result in an xcr0 value which has X86_XSTATE_MPX set in x32 mode. As everyone eventually calls amd64_create_target_description to build their target description, I figured we could assert in here that if X86_XSTATE_MPX is set then we should not be an x32 target, this will uncover any other bugs in this area. I'm not currently able to build/run any x32 binaries, so I have no way to test this, but the author of commit 4bb20a6244b7091 did test this series with that assert in place and didn't see any problems. [1] https://inbox.sourceware.org/gdb-patches/cover.1714143669.git.aburgess@redhat.com Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511 Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
2024-05-07gdb.base/watchpoint-running.exp: Run sw watch tests even if no hw watchPedro Alves1-1/+1
The code in gdb.base/watchpoint-running.exp that is trying to skip testing with hardware watchpoints also skips testing with software watchpoints if hardware watchpoints aren't supported by the target. This fixes it. Change-Id: Iaed62ac827b32b4fd73b732ad81fa4a5aa5784ba
2024-05-07Remove gdb.base/watchpoint-running.exp leftoverPedro Alves1-2/+0
Remove accidentally leftover commented-out line from gdb.base/watchpoint-running.exp. Change-Id: Ie1c3b85997d2ca92a2159a539d24b02fd3c9e697
2024-05-07gdb/testsuite/lib/rocm: Fix with_rocm_gpu_lockLancelot SIX1-1/+1
A recent commit refactored with_rocm_gpu_lock: commit fbb0edfe60edf4ca01884151e6d9b1353aaa0a7e Date: Sat May 4 10:41:09 2024 +0200 [gdb/testsuite] Factor out proc with_lock Factor out proc with_lock from with_rocm_gpu_lock, and move required procs lock_file_acquire and lock_file_release to lib/gdb-utils.exp. This causes regressions in gdb.rocm/*.exp (as well as in downstream rocgdb). The issue can be reproduced in the following minimal test: load_lib rocm.exp set foo hello with_rocm_gpu_lock { verbose -logs $foo } The issue is that the body to execute under the lock is executed in the context of with_rocm_gpu_lock (uplevel 1 used in with_lock) instead of in the context of the "original" caller. This patch adjusted with_rocm_gpu_lock to account for the new extra frame in the call stack between the caller of with_rocm_gpu_lock and where the code execution is triggered. Approved-By: Tom de Vries <tdevries@suse.de> Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe
2024-05-06Fix build issues with mingw toolchainBernd Edlinger2-0/+3
With a x86_64-pc-mingw32 toolchain there is a build issue whether or not the --disable-threading option is used. The problem happens because _WIN32_WINNT is defined to 0x501 before #include <mutex> which makes the compilation abort due to missing support for __gthread_cond_t in std_mutex.h, which is conditional on _WIN32_WINNT >= 0x600. Fix the case when --disable-threading is used, by only including <mutex> in gdb/complaints.c when STD_CXX_THREAD is defined. Additionally make the configure script try to #include <mutex> to automatically select --disable-threading when the header file is not able to compile. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-06[gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attachTom de Vries9-39/+135
When running the testsuite on a system with kernel.yama.ptrace_scope set to 1, we run into attach failures. Fix this by recognizing "ptrace: Operation not permitted" in can_spawn_for_attach. Tested on aarch64-linux and x86_64-linux. Approved-By: Pedro Alves <pedro@palves.net>
2024-05-06[gdb/exp] Redo cast handling for indirectionTom de Vries2-6/+4
In commit ed8fd0a342f ("[gdb/exp] Fix cast handling for indirection"), I introduced the behaviour that even though we have: ... (gdb) p *a_loc () 'a_loc' has unknown return type; cast the call to its declared return type ... we get: ... (gdb) p (char)*a_loc () $1 = 97 'a' ... In other words, the unknown return type of a_loc is inferred from the cast, effectually evaluating: ... (gdb) p (char)*(char *)a_loc () ... This is convient for the case that errno is defined as: ... #define errno (*__errno_location ()) ... and the return type of __errno_location is unknown but the macro definition is known, such that we can use: ... (gdb) p (int)errno ... instead of ... (gdb) p *(int *)__errno_location () ... However, as Pedro has pointed out in post-commit review [1], this makes it harder to reason about the semantics of an expression. For instance, this: ... (gdb) p (long long)*a_loc ()" ... would be evaluated without debug info as: ... (gdb) p (long long)*(long long *)a_loc ()" ... but with debug info as: ... (gdb) p (long long)*(char *)a_loc ()" ... Fix this by instead simply erroring out for this case: ... (gdb) p (char)*a_loc () 'a_loc' has unknown return type; cast the call to its declared return type ... Tested on x86_64-linux. Approved-By: Pedro Alves <pedro@palves.net> [1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html
2024-05-04Fix heap-use-after-free in index-cached with --disable-threadingHannes Domani1-1/+1
If threads are disabled, either by --disable-threading explicitely, or by missing std::thread support, you get the following ASAN error when loading symbols: ==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68 READ of size 1 at 0x614000002128 thread T0 #0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163 #1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601 #2 0x1705e39 in std::function<void ()>::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690 #3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38 0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8) freed by thread T0 here: #0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177 #1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689 #2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657 #3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300 It's happening because cooked_index_worker::wait always returns true in this case, which tells cooked_index::wait it can delete the m_state cooked_index_worker member, but cooked_index_worker::write_to_cache tries to access it immediately afterwards. Fixed by making cooked_index_worker::wait only return true if desired_state is CACHE_DONE, same as if threading was enabled, so m_state will not be prematurely deleted. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694 Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04Remove dwarf2_per_objfile::adjustTom Tromey2-15/+0
All the calls to dwarf2_per_objfile::adjust have been removed, so we can remove this function entirely. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31261
2024-05-04Remove call to dwarf2_per_objfile::adjust from read_attribute_valueTom Tromey1-1/+0
Currently, read_attribute_value calls dwarf2_per_objfile::adjust on any address. This seems wrong, because the address may not even be in the text section. Luckily, this call is also not needed, because read_func_scope calls 'relocate', which does the same work.
2024-05-04Remove call to dwarf2_per_objfile::adjust from read_call_site_scopeTom Tromey1-5/+2
read_call_site_scope does not need to call 'adjust', because in general the call site is not a symbol address, but rather just the address of some particular call.
2024-05-04Remove more calls to dwarf2_per_objfile::adjustTom Tromey1-18/+8
As with the previous patch, this patch removes some calls to dwarf2_per_objfile::adjust. These calls are not needed by the cooked indexer, as it does not create symbols or look up symbols by address. The call in dwarf2_ranges_read is similarly not needed, as it is only used to update an addrmap; and in any case I believe this particular call is only reached by the indexer.
2024-05-04Remove call to dwarf2_per_objfile::adjust from ranges readersTom Tromey2-4/+0
dwarf2_per_objfile::adjust applies gdbarch_adjust_dwarf2_addr to an address, leaving the result unrelocated. However, this adjustment is only needed for text-section symbols -- it isn't needed for any sort of address mapping. Therefore, these calls can be removed from read_addrmap_from_aranges and create_addrmap_from_gdb_index. Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-04[gdb/testsuite] Use unique portnum in parallel testing (check//% case)Tom de Vries2-2/+11
Make target check//% is the gdb variant of a similar gcc make target [1]. When running tests using check//%: ... $ cd build/gdb $ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp ... we get: ... $ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum 2427 $ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum 2423 ... The problem is that there are two portnum files used in parallel. Fix this by: - creating a common lockdir build/gdb/testsuite.lockdir for make target check//%, - passing this down to the runtests invocations using variable GDB_LOCK_DIR, and - using GDB_LOCK_DIR in lock_dir. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com> PR testsuite/31632 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632 [1] https://gcc.gnu.org/install/test.html
2024-05-04[gdb/testsuite] Use unique portnum in parallel testingTom de Vries1-9/+38
When instrumenting get_portnum using: ... puts "PORTNUM: $res" ... and running: ... $ cd build/gdb $ make check-parallel -j2 TESTS=gdb.server/*.exp ... we run into: ... Running gdb.server/abspath.exp ... PORTNUM: 2345 ... and: ... Running gdb.server/bkpt-other-inferior.exp ... PORTNUM: 2345 ... This is because the test-cases are run in independent runtest invocations. Fix this by handling the parallel case in get_portnum using: - a file $objdir/cache/portnum to keep the portnum variable, and - a file $objdir/cache/portnum.lock to serialize access to it. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Move gpu-parallel.lock to cache dirTom de Vries1-1/+1
The lock directory returned by lock_dir is currently $objdir. It seems possible to leave a stale lock file that blocks progress in a following run. Fix this by using a directory that is guaranteed to be initially empty when using GDB_PARALLEL, like temp or cache. In gdb/testsuite/README I found: ... cache in particular is used to share data across invocations of runtest ... which seems appropriate, so let's use cache for this. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Factor out proc lock_dirTom de Vries2-1/+8
In lib/rocm.exp we have: ... set gpu_lock_filename $objdir/gpu-parallel.lock ... This decides both the lock file name and directory. Factor out a new proc lock_dir that decides on the directory, leaving just: ... set gpu_lock_filename gpu-parallel.lock ... Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Factor out proc with_lockTom de Vries2-54/+60
Factor out proc with_lock from with_rocm_gpu_lock, and move required procs lock_file_acquire and lock_file_release to lib/gdb-utils.exp. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Make portnum a persistent globalTom de Vries1-1/+1
When instrumenting get_portnum using: ... puts "PORTNUM: $res" ... and running: ... $ cd build/gdb $ make check TESTS=gdb.server/*.exp ... we get: ... Running gdb.server/target-exec-file.exp ... PORTNUM: 2345 Running gdb.server/stop-reply-no-thread-multi.exp ... PORTNUM: 2345 PORTNUM: 2346 PORTNUM: 2347 PORTNUM: 2348 PORTNUM: 2349 PORTNUM: 2350 ... So, while get_portnum does return increasing numbers in a single test-case, it restarts at each test-case. This is a regression since the introduction of persistent globals. Fix this by using "gdb_persistent_global portnum", such that we get: ... Running gdb.server/target-exec-file.exp ... PORTNUM: 2345 Running gdb.server/stop-reply-no-thread-multi.exp ... PORTNUM: 2346 PORTNUM: 2347 PORTNUM: 2348 PORTNUM: 2349 PORTNUM: 2350 PORTNUM: 2351 ... Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-04[gdb/testsuite] Factor out proc get_portnumTom de Vries1-11/+29
In gdbserver_start, we have some code that determines what port number to use: ... # Port id -- either specified in baseboard file, or managed here. if [target_info exists gdb,socketport] { set portnum [target_info gdb,socketport] } else { # Bump the port number to avoid conflicts with hung ports. incr portnum } ... Factor this out into a new proc get_portnum. Tested on aarch64-linux. Approved-By: Tom Tromey <tom@tromey.com>
2024-05-03Adjust gdb_continue_to_end for WindowsPedro Alves1-0/+15
On Cygwin, supposely single-threaded programs are always multi-threaded, due to the extra threads spawned by the Cygwin runtime. Because of that, any gdb_continue_to_end call that doesn't specify "allow_extra" fails, like so: (gdb) PASS: gdb.base/langs.exp: show language at main continue Continuing. [Thread 16140.0x1fbc exited with code 0] [Thread 16140.0x2458 exited with code 0] [Thread 16140.0x3494 exited with code 0] [Inferior 1 (process 16140) exited normally] (gdb) FAIL: gdb.base/langs.exp: continue until exit at first session (the program exited) Similarly, with this simple program compiled with MinGW: $ cat ~/sleeper.c #include <windows.h> int main () { Sleep (2000); return 0; } and with a MinGW GDB, I see: (gdb) start ... (gdb) info threads Id Target Id Frame * 1 Thread 15292.0x3850 main () at /home/alves/sleeper.c:5 2 Thread 15292.0x3048 0x00007ff9630d2fb7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll (gdb) c Continuing. [Thread 15292.0x3850 exited with code 0] [Inferior 1 (process 15292) exited normally] (gdb) This commit adjusts gdb_continue_to_end to expect the thread exited messages, on Cygwin and MinGW. Change-Id: I5e410a7252c11cd9ecea632f1e00c2a7fcd69098 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-05-03[gdb/testsuite] Use save_vars to restore GDBFLAGSTom de Vries25-187/+165
There's a pattern of using: ... set saved_gdbflags $GDBFLAGS set GDBFLAGS "$GDBFLAGS ..." <do something with GDBFLAGS> set GDBFLAGS $saved_gdbflags ... Simplify this by using save_vars: ... save_vars { GDBFLAGS } { set GDBFLAGS "$GDBFLAGS ..." <do something with GDBFLAGS> } ... Tested on x86_64-linux.
2024-05-03[gdb/testsuite] Remove superfluous -quiet and -ex set width/height 0Tom de Vries9-16/+5
INTERNAL_GDBFLAGS contains: - -quiet - -iex "set width 0" - -iex "set height 0" There are test-cases that add these once more. Clean this up. Tested on x86_64-linux. PR testsuite/31649 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31649
2024-05-03[gdb/testsuite] Update INTERNAL_GDBFLAGS exampleTom de Vries1-1/+1
In commit 31c50280179 ("[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS") I added -q to the INTERNAL_GDBFLAGS, but I forgot to update the INTERNAL_GDBFLAGS example in gdb/testsuite/README. Fix this by adding the -q there as well.
generated by cgit v1.1 at 2025-02-07 02:41:24 +0000