aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-04-01Automatic date update in version.inGDB Administrator1-1/+1
2025-03-31testsuite: fix is_aarch32_targetThiago Jung Bauermann1-6/+9
Commit c221b2f77080 Testsuite: Add gdb_can_simple_compile changed the source file name extension of the test program from .s to .c resulting in compile fails. This, in turn, causes is_aarch32_target checks to fail. Change the test source from an assembly program to a C program using inline assembly. is_amd64_regs_target had a similar problem, which was fixed by commit 224d30d39365 testsuite: fix is_amd64_regs_target This fix — and commit message — are mostly copied from it. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-31gdbserver: Add support for MicroBlaze host microblaze*-*-linux*Michael Eager3-0/+253
Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com> Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com> Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com> Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com> Signed-off-by: Michael Eager <eager@eagercon.com>
2025-03-31[gdb/record] Make enum gdb_syscall value names consistentTom de Vries7-14/+14
In enum gdb_syscall, there are 3 entries that do not have the gdb_sys_ prefix ... $ grep gdb_old_ gdb/linux-record.h gdb_old_select = 82, gdb_old_readdir = 89, gdb_old_mmap = 90, ... like all the other entries: ... gdb_sys_restart_syscall = 0, gdb_sys_exit = 1, gdb_sys_fork = 2, gdb_sys_read = 3, ... The three correspond to these entries in arch/x86/entry/syscalls/syscall_32.tbl: ... <number> <abi> <name> <entry point> [<compat entry point> [noreturn]] 82 i386 select sys_old_select compat_sys_old_select 89 i386 readdir sys_old_readdir compat_sys_old_readdir 90 i386 mmap sys_old_mmap compat_sys_ia32_mmap ... As we can see, the enum uses the entry point name, but without the sys_ prefix. There doesn't seem to be a good reason for this. There's another enum value: ... gdb_sys_old_getrlimit = 76, ... corresponding to: ... 76 i386 getrlimit sys_old_getrlimit compat_sys_old_getrlimit ... where we do use the sys_ prefix. Fix this by consistenly using the gdb_sys_ prefix in enum gdb_syscall. No functional changes. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2025-03-31[gdb/contrib] Remove spellcheck.shTom de Vries2-566/+0
Now that we've started using codespell, remove gdb/contrib/spellcheck.sh and associated file gdb/contrib/common-misspellings.txt. Approved-By: Tom Tromey <tom@tromey.com>
2025-03-31[gdb] Check strpbrk against nullptrTom de Vries2-2/+2
In noticed two occurrences of "if (strpbrk (...))". Fix this style issue by checking against nullptr.
2025-03-31gdbsupport/common-inferior.c: Fix mingw buildLancelot SIX1-1/+1
A recent change (512ca2fca4b "gdb: split up construct_inferior_arguments") introduced a build failure for mingw: CXX common-inferior.o .../gdb/gdbsupport/common-inferior.cc: In function ‘std::string escape_characters(const char*, const char*)’: .../gdb/gdbsupport/common-inferior.cc:62:20: error: ‘argv’ was not declared in this scope; did you mean ‘arg’? 62 | if (strpbrk (argv[i], special)) | ^~~~ | arg .../gdb/gdbsupport/common-inferior.cc:62:25: error: ‘i’ was not declared in this scope 62 | if (strpbrk (argv[i], special)) | ^ This patch fixes that. Change-Id: I07ade607bc4516627b433085b07d9d198d8e4b4a Approved-By: Tom de Vries <tdevries@suse.de>
2025-03-31ld/PE: Add another mingw UCRT library name to the autoexport exclusion listMartin Storsjö1-0/+1
Since 2020, mingw-w64 provides a C runtime import library variant named "libucrtapp" too, exclude this one from autoexports like the others. Signed-off-by: Martin Storsjö <martin@martin.st>
2025-03-31[pre-commit] Add codespell hookTom de Vries3-5/+9
Add a pre-commit codespell hook for directories gdbsupport and gdbserver, which are codespell-clean: ... $ pre-commit run codespell --all-files codespell................................................................Passed ... A non-trivial question is where the codespell configuration goes. Currently we have codespell sections in gdbsupport/setup.cfg and gdbserver/setup.cfg, but codespell doesn't automatically use those because the pre-commit hook runs codespell at the root of the repository. A solution would be to replace those 2 setup.cfg files with a setup.cfg in the root of the repository. Not ideal because generally we try to avoid adding files related to subdirectories at the root. Another solution would be to add two codespell hooks, one using --config gdbsupport/setup.cfg and one using --config gdbserver/setup.cfg, and add a third one once we start supporting gdb. Not ideal because it creates duplication, but certainly possible. I went with the following solution: a setup.cfg file in gdb/contrib (alongside codespell-ignore-words.txt) which is used for both gdbserver and gdbsupport. So, what can this new setup do for us? Let's demonstrate by simulating a typo: ... $ echo "/* aways */" >> gdbsupport/agent.cc ... We can check unstaged changes before committing: ... $ pre-commit run codespell --all-files codespell................................................................Failed - hook id: codespell - exit code: 65 gdbsupport/agent.cc:282: aways ==> always, away ... Likewise, staged changes (no need for the --all-files): ... $ git add gdbsupport/agent.cc $ pre-commit run codespell codespell................................................................Failed - hook id: codespell - exit code: 65 gdbsupport/agent.cc:282: aways ==> always, away ... Or we can try to commit, and run into the codespell failure: ... $ git commit -a black................................................(no files to check)Skipped flake8...............................................(no files to check)Skipped isort................................................(no files to check)Skipped codespell................................................................Failed - hook id: codespell - exit code: 65 gdbsupport/agent.cc:282: aways ==> always, away check-include-guards.................................(no files to check)Skipped ... which makes the commit fail. Approved-By: Tom Tromey <tom@tromey.com>
2025-03-31Automatic date update in version.inGDB Administrator1-1/+1
2025-03-30[gdb/tdep] Fix mmap syscall mappingTom de Vries3-3/+3
There are a few spots where an mmap system call is mapped onto enum gdb_syscall value gdb_sys_mmap2. Strictly speaking, this is incorrect. Fix this by mapping to enum gdb_syscall value gdb_old_mmap instead. No functional changes: both gdb_old_mmap and gdb_sys_mmap2 are handled the same in record_linux_system_call. Tested by rebuilding on x86_64-linux.
2025-03-30[gdb] Skip selftest with warningTom de Vries4-21/+29
With the selftest register_name, we run into a few warning: ... $ gdb -q -batch -ex "maint selftest register_name" 2>&1 \ | grep -B1 warning: Running selftest register_name::m68hc11. warning: No frame soft register found in the symbol table. -- Running selftest register_name::m68hc12. warning: No frame soft register found in the symbol table. -- Running selftest register_name::m68hc12:HCS12. warning: No frame soft register found in the symbol table. ... We already filter out these architectures in other selftests because of the same warning. Do the same in this selftest. Tested on x86_64-linux. Approved-By: Andrew Burgess <aburgess@redhat.com>
2025-03-30Automatic date update in version.inGDB Administrator1-1/+1
2025-03-29gdb: remove disable_breakpoints_in_shlibs functionAndrew Burgess5-41/+89
I think there is a problem with the disable_breakpoints_in_shlibs function: it can disable breakpoint locations without calling notify_breakpoint_modified. This means that the Python API's breakpoint_modified event will not trigger, nor will the MI send a breakpoint modified event. I started looking at disable_breakpoints_in_shlibs because of an earlier commit: commit 8c48ec7a6160aed0d1126c623443935e4435cd41 Date: Thu Aug 29 12:34:15 2024 +0100 gdb: handle dprintf breakpoints when unloading a shared library Currently disable_breakpoints_in_shlibs is only called from one location, clear_solib in solib.c. clear_solib also calls notify_solib_unloaded for every solib in the program_space of interest, and notify_solib_unloaded will call disable_breakpoints_in_unloaded_shlib via the solib_unloaded observer. These two function, disable_breakpoints_in_shlibs and disable_breakpoints_in_unloaded_shlib are very similar in what they do. I think that we can remove the disable_breakpoints_in_shlibs call, and instead, tweak how we call disable_breakpoints_in_unloaded_shlib in order to get the same end result, except that, after this change, we will call notify_breakpoint_modified, which means the Python API event will trigger, and the MI events will be emitted. All that disable_breakpoints_in_shlibs does is disable some breakpoints. Meanwhile, disable_breakpoints_in_unloaded_shlib, will disable the same set of breakpoints, call notify_breakpoint_modified, and then (for some breakpoint types) print a message telling the user that the breakpoint has been disabled. However, this function will ignore any breakpoints that are already disabled. As disable_breakpoints_in_shlibs disables the same set of breakpoints, the result of the current code is that disable_breakpoints_in_shlibs serves only to prevent the notify_breakpoint_modified call, which I think is wrong, and to prevent the user message being printed, which I think is reasonable. If we remove the disable_breakpoints_in_shlibs call without making any additional changes, then we start to see some message printed in cases like this: (gdb) start The program being debugged has been started already. Start it from the beginning? (y or n) y warning: Temporarily disabling breakpoints for unloaded shared library "/tmp/shared-lib-test/libfoo.so" Temporary breakpoint 3 at 0x40113e: file test.c, line 9. Starting program: /tmp/shared-lib-test/test.x Notice the 'warning:' line, which is new. I think this is confusing because, in most cases the breakpoint will be enabled again by the time the inferior reaches `main` and stops. In the future I'm interested in exploring if GDB could be smarter about when to print these 'Temporarily disabling breakpoints ...' messages so that if the 'start' command does mean a breakpoint is left disabled, then the user would be informed. However, I don't propose doing that work immediately, and certainly not in this commit. For now, my intention is to leave things as they are right now, GDB doesn't warn about disabling breakpoints during an inferior re-start. To achieve this I think we need to pass a new argument to disable_breakpoints_in_unloaded_shlib which controls whether we should print a message about the breakpoint being disabled or not. With this added we can now silence the warning when the inferior is restarted (i.e. when disable_breakpoints_in_unloaded_shlib is called from clear_solib), but keep the warning for cases like stepping over a dlclose() call in the inferior. After this commit, GDB now emits breakpoint modified events (in Python and/or MI) when a breakpoint is disabled as a result of all shared libraries being unloaded. This will be visible in two places that I can thing of, the 'nosharedlibrary' command, and when an inferior is restarted.
2025-03-29x86: Add {noimm8s} pseudo prefixH.J. Lu10-173/+327
Instruction templates with only sign-extended 8-bit immediate operand also have a second template with full-operand-size immediate operand under a different opcode. Add {noimm8s} pseudo prefix to exclude templates with only sign-extended 8-bit immediate operand. gas/ PR gas/32811 * config/tc-i386.c (pseudo_prefixes): Add no_imm8s. (operand_size_match): Return false for templates with only sign- extended 8-bit immediate operand if {noimm8s} is used. (parse_insn): Handle Prefix_NoImm8s. * doc/c-i386.texi: Document {noimm8s}. * testsuite/gas/i386/pseudos.s: Add tests for {noimm8s}. * testsuite/gas/i386/x86-64-pseudos.s: Likewise. * testsuite/gas/i386/pseudos.d: Updated. * testsuite/gas/i386/x86-64-pseudos.d: Likewise. opcodes/ PR gas/32811 * opcodes/i386-opc.h (Prefix_NoImm8s): New. * i386-opc.tbl: Add {noimm8s} pseudo prefix. * i386-mnem.h: Regenerated. * i386-tbl.h: Likewise. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-03-29gprof: Always compile tests with -gH.J. Lu2-12/+10
Always compile gprof testsuite with -g for line number info checked by tst-gmon-gprof-l.sh. PR gprof/32779 * testsuite/Makefile.am (GPROF_FLAGS): Add -g. (COMPILE): Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS)". (LINK) Set to "$(CC) $(AM_CFLAGS) $(GPROF_FLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@". * testsuite/Makefile.in: Regenerated. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
2025-03-29Automatic date update in version.inGDB Administrator1-1/+1
2025-03-28gdb: reduce breakpoint-modified events for dprintf b/pAndrew Burgess6-0/+270
Consider this backtrace within GDB: #0 notify_breakpoint_modified (b=0x57d31d0) at ../../src/gdb/breakpoint.c:1083 #1 0x00000000005b6406 in breakpoint_set_commands (b=0x57d31d0, commands=...) at ../../src/gdb/breakpoint.c:1523 #2 0x00000000005c8c63 in update_dprintf_command_list (b=0x57d31d0) at ../../src/gdb/breakpoint.c:8641 #3 0x00000000005d3c4e in dprintf_breakpoint::re_set (this=0x57d31d0) at ../../src/gdb/breakpoint.c:12476 #4 0x00000000005d6347 in breakpoint_re_set () at ../../src/gdb/breakpoint.c:13298 Whenever breakpoint_re_set is called we re-build the commands that the dprintf b/p will execute and store these into the breakpoint. The commands are re-built in update_dprintf_command_list and stored into the breakpoint object in breakpoint_set_commands. Now sometimes these commands can change, dprintf_breakpoint::re_set explains one case where this can occur, and I'm sure there must be others. But in most cases the commands we recalculate will not change. This means that the breakpoint modified event which is emitted from breakpoint_set_commands is redundant. This commit aims to eliminate the redundant breakpoint modified events for dprintf breakpoints. This is done by adding a commands_equal call to the start of breakpoint_set_commands. The commands_equal function is a new function which compares two command_line objects and returns true if they are identical. Using this function we can check if the new commands passed to breakpoint_set_commands are identical to the breakpoint's existing commands. If the new commands are equal then we don't need to change anything on the new breakpoint, and the breakpoint modified event can be skipped. The test for this commit stops at a dlopen() call in the inferior, sets up a dprintf breakpoint, then uses 'next' to step over the dlopen() call. When the library loads GDB call breakpoint_re_set, which calls dprintf_breakpoint::re_set. But in this case we don't expect the calculated command string to change, so we don't expect to see the breakpoint modified event.
2025-03-28Fix gstack issuesKeith Seitz2-6/+8
With commit fb2ded33c1e519659743047ed7817166545b6d91, I added Fedora's gstack script to gdb. Some issues have arisen since then, and this patch addresses those issues: . As Sam James recently noted[1], PKGVERSION and VERSION need to be quoted. . A Fedora user reported the misuse of --readnever, which causes gstack to omit filename and line number information in the backtrace[Red Hat BZ 2354997]. [1] https://inbox.sourceware.org/gdb-patches/d19d6bc17e0a160ce27fc572079f11a587c0e168.1742424869.git.sam@gentoo.org/ Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2354997
2025-03-28x86: Pass $NOPIE_LDFLAGS to undefined weak testsJens Remus1-2/+2
Some distributions configure GCC with --enable-default-pie, so that it defaults to compile with -fPIE and link with -pie, which is unexpected by some of the tests. Therefore link the PDE test programs with $NOPIE_LDFLAGS to disable PIE. This complements commit a7eaf017f959 ("Use NOPIE_CFLAGS and NOPIE_LDFLAGS to disable PIE"). ld/testsuite/ PR ld/21090 * ld-x86-64/x86-64.exp (undefined_weak): Use NOPIE_LDFLAGS to disable PIE for the non-PIE versions of the test. Bug: https://sourceware.org/PR21090 Signed-off-by: Jens Remus <jremus@linux.ibm.com>
2025-03-28ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF visibility testsJens Remus1-7/+9
Some distributions configure GCC with --enable-default-pie, so that it defaults to compile with -fPIE and link with -pie, which is unexpected by the test. Therefore compile the non-PIC sources with $NOPIE_CFLAGS and link the test programs with $NOPIE_LDFLAGS. Commit 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests") added $NOPIE_CFLAGS when compiling sh1np.o and sh2np.o. It missed to add it to mainnp.o. ld/testsuite/ PR ld/21090 * ld-vsb/vsb.exp (visibility_test): Add support for optional ldflags argument and use it when linking the test program. (mainnp.o): Compile with $NOPIE_CFLAGS. (vnp, vp, vmpnp, vmpp): Link with $NOPIE_LDFLAGS. Fixes: 922109c71828 ("Pass $NOPIE_CFLAGS to ELF visibility tests") Bug: https://sourceware.org/PR21090 Signed-off-by: Jens Remus <jremus@linux.ibm.com>
2025-03-28ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to even more ELF shared testsJens Remus1-16/+18
Some distributions configure GCC with --enable-default-pie, so that it defaults to compile with -fPIE and link with -pie, which is unexpected by the test. Therefore compile the non-PIC sources with $NOPIE_CFLAGS and link the test programs with $NOPIE_LDFLAGS. Commit 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF tests") added $NOPIE_CFLAGS when compiling sh1np.o. It missed to add it to sh2np.o and mainnp.o. ld/testsuite/ PR ld/21090 * ld-shared/shared.exp (shared_test): Add support for optional ldflags argument and use it when linking the test program. (sh2np.o, mainnp.o): Compile with $NOPIE_CFLAGS. (shnp, shp, shmpnp, shmpp): Link with $NOPIE_LDFLAGS. Fixes: 9d1c54ed7f3a ("Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF tests") Bug: https://sourceware.org/PR21090 Signed-off-by: Jens Remus <jremus@linux.ibm.com>
2025-03-28ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr21964-4Jens Remus1-2/+2
Linker test "pr21964-4" fails on s390x on Ubuntu 24.10 but not on Fedora 41. The reason is that GCC on Ubuntu is configured with --enable-default-pie, so that it defaults to compile with -fPIE and link with -pie, which causes the test to erroneously fail. ld/testsuite/ PR ld/21090 * ld-elf/shared.exp: Compile pr21964-4 with $NOPIE_CFLAGS and link with $NOPIE_LDFLAGS. Bug: https://sourceware.org/PR21090 Signed-off-by: Jens Remus <jremus@linux.ibm.com>
2025-03-28ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr19719Jens Remus1-1/+1
Linker test "pr19719 fun defined" (non PIE) fails on s390x on Fedora 41 but not on Ubuntu 24.10. The reason is that GCC on Ubuntu is configured with --enable-default-pie, so that it defaults to compile with -fPIE and link with -pie, which hides the test fail. ld/testsuite/ PR ld/21090 * ld-elf/shared.exp: Compile pr19719 (non-PIE) with $NOPIE_CFLAGS and link with $NOPIE_LDFLAGS. Bug: https://sourceware.org/PR21090 Signed-off-by: Jens Remus <jremus@linux.ibm.com>
2025-03-28RISC-V: Don't show support for 1.9.1 priv specMarek Pikuła1-3/+6
The privileged spec 1.9.1 support was removed since binutils 2.43. The linker only recognizes it and then reports a warning that it may conflict with other spec versions. While the support is removed, binutils should still recognize it, but it shouldn't be exposed to the user in `disassember-options` help. Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
2025-03-28doc/riscv: Add description of disassembler optionsMarek Pikuła1-0/+17
Up to this point, no mention of RISC-V-specific disassembler options was mentioned in binutils documentation. This patch includes description for all of the currently supported options. Signed-off-by: Marek Pikuła <m.pikula@partner.samsung.com>
2025-03-28Automatic date update in version.inGDB Administrator1-1/+1
2025-03-27gdb: Fix assertion failure when inline frame #0 is duplicatedCraig Blackmore2-69/+96
Modifying inline-frame-cycle-unwind.exp to use `bt -no-filters` produces the following incorrect backtrace: #0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49 #1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32 #2 0x000055555555517f in inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:50 #3 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1 The expected output, which we get with `bt`, is: #0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49 #1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1 The cycle checking in `get_prev_frame_maybe_check_cycle` relies on newer frame ids having already been computed and stashed. Unlike other frames, frame #0's id does not get computed immediately. The test passes with `bt` because when applying python frame filters, the call to `bootstrap_python_frame_filters` happens to compute the id of frame #0. When `get_prev_frame_maybe_check_cycle` later tries to stash frame #2's id, the cycle is detected. The test fails with `bt -no-filters` because frame #0's id has not been stashed by the time `get_prev_frame_maybe_check_cycle` tries to stash frame #2's id which succeeds and the cycle is only detected later when trying to stash frame #4's id. Doing `stepi` after the incorrect backtrace would then trigger an assertion failure when trying to stash frame #0's id because it is a duplicate of #2's already stashed id. In `get_prev_frame_always_1`, if this_frame is inline frame 0, then compute and stash its frame id before returning the previous frame. This ensures that the id of inline frame 0 has been stashed before `get_prev_frame_maybe_check_cycle` is called on older frames. The test case has been updated to run both `bt` and `bt -no-filters`. Co-authored-by: Andrew Burgess <aburgess@redhat.com>
2025-03-27[gdb/contrib] Drop two words from codespell-ignore-words.txtTom de Vries3-4/+2
Tom Tromey mentioned [1] that the words "invokable" and "useable" present in codespell-ignore-words.txt should be dropped. Do so and fix the following typos: ... $ codespell --config gdbsupport/setup.cfg gdbsupport gdbsupport/common-debug.h:218: invokable ==> invocable gdbsupport/event-loop.cc:84: useable ==> usable ... Approved-By: Tom Tromey <tom@tromey.com> [1] https://sourceware.org/pipermail/gdb-patches/2025-March/216584.html
2025-03-27[gdb/contrib] Add SME to codespell-ignore-words.txtTom de Vries1-0/+1
Ignore the following codespell detection: ... $ codespell --config gdbserver/setup.cfg gdbserver gdbserver/linux-aarch64-low.cc:827: SME ==> SAME, SEME, SOME, SMS ... by adding SME to codespell-ignore-words.txt.
2025-03-27[gdbserver] Fix typo in tracepoint.ccTom de Vries1-1/+1
Fix a typo: ... $ codespell --config gdbserver/setup.cfg gdbserver/tracepoint.cc gdbserver/tracepoint.cc:951: mistakingly ==> mistakenly ...
2025-03-27[gdbsupport] Ignore pathc in codespell check in gdb_tilde_expand.ccTom de Vries1-2/+2
Ignore the following codespell detections: ... $ codespell --config gdbsupport/setup.cfg gdbsupport gdbsupport/gdb_tilde_expand.cc:54: pathc ==> patch gdbsupport/gdb_tilde_expand.cc:99: pathc ==> patch ... by adding codespell:ignore comments.
2025-03-27[gdbsupport] Fix a typo in common-debug.hTom de Vries1-1/+1
Fix a typo: ... $ codespell --config gdbsupport/setup.cfg gdbsupport/common-debug.h gdbsupport/common-debug.h:109: re-used ==> reused ...
2025-03-27gdb/dap - Add CompletionsRequestoltolm5-2/+85
Use GDB/MI command "-complete" to implement. Co-authored-by: Simon Farre <simon.farre.cx@gmail.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31140 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2025-03-27[gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.expTom de Vries2-5/+12
In OBS (Open Build Service), with a 15.2 based gdb package, occasionally I run into: ... (gdb) inferior 2 [Switching to inferior 2 [process 31372] (access-mem-running-thread-exit)] [Switching to thread 2.1 (Thread 0xf7db9700 (LWP 31372))](running) (gdb) print global_var = 555 $1 = 555 (gdb) print global_var $2 = 556 (gdb) FAIL: $exp: all-stop: access mem \ (print global_var after writing, inf=2, iter=1) ... I managed to reproduce this on current trunk using a reproducer patch (posted in the PR). The problem is due to commit 31c21e2c13d ("[gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp with clang"), which introduced an increment of global_var at the start of main. This created a race between: - gdb modifying global_var, and - the inferior modifying global_var. Fix this by: - adding a new empty function setup_done, - adding a call to setup_done after the increment of global_var, and - rather than running to main, running to setup_done. Tested on x86_64-linux. PR testsuite/32822 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32822
2025-03-27x86: Remove AVX10.2 256 bit rounding supportHaochen Jiang36-2826/+93
Since we will support 512 bit on both P-core and E-core for AVX10, 256 bit rounding is not that useful because we currently have rounding feature directly on E-core now and no need to use 256-bit rounding as somehow a workaround. This patch will remove all the support and backport to Binutils 2.44. gas/ChangeLog: * NEWS: Mention support removal. * config/tc-i386.c (build_evex_prefix): Remove U bit encode. (check_VecOperands): Remove ymm check for rounding. (s_insn): Revise .insn comment. * testsuite/gas/i386/avx10_2-256-cvt-intel.d: Remove ymm rounding related test. * testsuite/gas/i386/avx10_2-256-cvt.d: Ditto. * testsuite/gas/i386/avx10_2-256-cvt.s: Ditto. * testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto. * testsuite/gas/i386/avx10_2-256-miscs.d: Ditto. * testsuite/gas/i386/avx10_2-256-miscs.s: Ditto. * testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto. * testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto. * testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto. * testsuite/gas/i386/evex.d: Ditto. * testsuite/gas/i386/evex.s: Ditto. * testsuite/gas/i386/i386.exp: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto. * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto. * testsuite/gas/i386/x86-64-evex.d: Ditto. * testsuite/gas/i386/x86-64.exp: Ditto. * testsuite/gas/i386/avx10_2-rounding-intel.d: Removed. * testsuite/gas/i386/avx10_2-rounding-inval.l: Removed. * testsuite/gas/i386/avx10_2-rounding-inval.s: Removed. * testsuite/gas/i386/avx10_2-rounding.d: Removed. * testsuite/gas/i386/avx10_2-rounding.s: Removed. * testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Removed. * testsuite/gas/i386/x86-64-avx10_2-rounding.d: Removed. * testsuite/gas/i386/x86-64-avx10_2-rounding.s: Removed. opcodes/ChangeLog: * i386-dis.c (struct instr_info): Remove U bit. (get_valid_dis386): Roll back to APX condition. * i386-opc.tbl: Remove ymm rounding support. * i386-tbl.h: Regenerated.
2025-03-27Automatic date update in version.inGDB Administrator1-1/+1
2025-03-26gdb/testsuite: Force DWARF debuginfo where applicable in AIX systemsGuinevere Larsen1-0/+17
In the AIX systems available for testing in the gcc compile farm, the default debug information format is stabs. This is a problem for many reasons, mainly that stabs is not as complete as dwarf and stabs is being deprecated in the next release. In the current state, we have: PASS: 39798 FAIL: 7405 When running these tests, I unfortunately didn't have the foresight to save the number of unsupported and untested cases. To improve testing there, this patch changes the gdb_compile TCL proc, so that if we're running tests in AIX, we requested debug info, and we haven't explicitly asked for some debuginfo format, gdb_compile will add -gdwarf to the compilation line, forcing DWARF to be used. After this patch, we get: PASS: 74548 FAIL: 5963 So not only do we have fewer failures, there are tens of thousands of tests that are no longer skipped. Approved-By: Tom Tromey <tom@tromey.com>
2025-03-26ld: Correct test pr19719 naming mix-upJens Remus1-4/+4
The suffix "defined/undefined" in the ld test pr19719 name specifies whether weak fun() is defined or undefined is mixed up. The test builds an executable and a shared library. The latter in two flavors, one with weak fun() defined (libpr19719a.so, "defined") and one without weak fun() defined (libpr19719b.so, "undefined"). The first "Run $exe fun [...]" invocation uses libpr19719b.so as libpr19719.so, which is build from dummy.c, which does not define fun. Thus fun is undefined during this test run. The second "Run $exe fun [...]" invocation uses libpr19719a.so as libpr19719.so, which is build from pr19719d.c, which does define fun. Thus fun is defined during this test run. Correct the test naming mix-up accordingly. ld/testsuite/ * ld-elf/shared.exp (mix_pic_and_non_pic): Correct test naming mix-up of when weak fun is un-/defined. Signed-off-by: Jens Remus <jremus@linux.ibm.com>
2025-03-26gdb: add configure option to disable compileGuinevere Larsen28-16/+166
GDB's compile subsystem is deeply tied to GDB's ability to understand DWARF. A future patch will add the option to disable DWARF at configure time, but for that to work, the compile subsystem will need to be entirely disabled as well, so this patch adds that possibility. I also think there is motive for a security conscious user to disable compile for it's own sake. Considering that the code is quite unmaintained, and depends on an equally unmaintained gcc plugin, there is a case to be made that this is an unnecessary increase in the attack surface if a user knows they won't use the subsystem. Additionally, this can make compilation slightly faster and the final binary is around 3Mb smaller. But these are all secondary to the main goal of being able to disable dwarf at configure time. To be able to achieve optional compilation, some of the code that interfaces with compile had to be changed. All parts that directly called compile things have been wrapped by ifdefs checking for compile support. The file compile/compile.c has been setup in a similar way to how python's and guile's main file has been setup, still being compiled but only for with placeholder command. Finally, to avoid several new errors, a new TCL proc was introduced to gdb.exp, allow_compile_tests, which checks if the "compile" command is recognized before the inferior is started and otherwise skips the compile tests. All tests in the gdb.compile subfolder have been updated to use that, and the test gdb.base/filename-completion also uses this. The proc skip_compile_feature_tests to recognize when the subsystem has been disabled at compile time. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2025-03-26gdb: Remove compile-related attributes from struct languageGuinevere Larsen6-113/+78
The following patch will add a configure option to disable the compile subsystem at compilation time. To do that, nearly all code that interfaces with compile should be confined to the compile sub-folder. This commit is the first step, removing the compile-related method from the language struct and adding 2 new functions to compile.c that do the same job in a slightly different way. Adding things to the language struct is a more extendable way to add support for languages, but considering compile is quite bit-rotted and questionably supported, I don't think it will be extended any time soon, and using ifdefs to handle disabling compile with configure felt like a messier solution. There should be no visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
2025-03-26gdb/dwarf: use reference in cutu_reader::cutu_reader interfaceSimon Marchi3-64/+60
Change some parameters to be references instead of pointers, when the value must not be nullptr. I'd like to do this more of this kind of change, but I have to limit the scope of the change, otherwise there's just no end (and some local variables could also be turned into references). So for now, just do it the cutu_reader constructors. Change-Id: I9442c6043726981d58f9b141f516c590c0a71bcc Approved-By: Tom Tromey <tom@tromey.com>
2025-03-26gdb/dwarf: update comment of cutu_reader::cutu_reader (the DWO variant)Simon Marchi1-13/+9
The comment on this constructor is really outdated. Update it to better reflect the reality today. I'd eventually like to change this cutu_reader constructor not to use dwarf2_per_cu, because it seems like an abuse of dwarf2_per_cu just to pass 3 values. But for now, just document the existing behavior. Change-Id: Id96db020c361e64d9b0d2f25d51950b206658aa2 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-26gdb/dwarf: remove redundant read of dwo_nameSimon Marchi1-4/+6
lookup_dwo_unit receives the name of the DWO unit to look up, as read from the DW_AT_dwo_name attribute of the skeleton DIE. But then, it doesn't use it: /* Yeah, we look dwo_name up again, but it simplifies the code. */ dwo_name = dwarf2_dwo_name (comp_unit_die, cu); Perhaps this comment made sense at some point, but with the code we have today, I don't understand it. It should be fine to use the name passed as a parameter, which the caller also obtained by calling dwarf2_dwo_name. Change-Id: I84723e12726f77e4202d042428ee0eed9962ceb8 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-26LoongArch: Fix disassembly option parsing stopping at the first optionWANG Xuerui5-1/+39
Turns out the return value of parse_loongarch_dis_option acts as an error code, and previously the function always signified failure with a non-zero return value, making only the first disassembly option get to take effect. Fix by adding the missing `return 0`'s to the two success code paths. Signed-off-by: WANG Xuerui <git@xen0n.name>
2025-03-26ld: Support RELRO in aarch64-elf targetRoland McGrath2-0/+2
Other *-elf targets set COMMONPAGESIZE in emulparams/*.sh and so enable `-z relro` and related features. Make aarch64-elf match. There is no reason to think that a "generic ELF" target should have any particular set of features disabled.
2025-03-26RISC-V: add Smrnmi 1.0 instruction supportJerry Zhang Jian6-0/+24
Add instruction `mnret' support Ref: https://github.com/riscv/riscv-isa-manual/blob/bb8b9127f81965eeff2d150c211d1c89376591c4/src/rnmi.adoc https://github.com/riscv/riscv-opcodes/blob/946eb673874b3a0f2474d1424dc28bc7ee53c306/extensions/rv_smrnmi bfd/ChangeLog: * elfxx-riscv.c: Add new Smrnmi instruction class handling gas/ChangeLog: * testsuite/gas/riscv/smrnmi.s: New test for mnret * testsuite/gas/riscv/rmrnmi.d: Likewise include/ChangeLog: * opcode/ricsv-opc.h: Add MATCH_MNRET, MASK_MNRET * opcode/riscv.h: Add new instruction class opcodes/ChangeLog: * riscv-opc.c: Add `mnret' instruction Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>
2025-03-26Automatic date update in version.inGDB Administrator1-1/+1
2025-03-25gdb/dwarf: use std::equal_range in cooked_index_shard::findSimon Marchi1-16/+19
Looking at `cooked_index_shard::find`, I thought that we could make a small optimization: when finding the upper bound, we already know the lower bound. And we know that the upper bound is >= the lower bound. So we could pass `lower` as the first argument of the `std::upper_bound` call to cut the part of the search space that is below `lower`. It then occured to me that what we do is basically what `std::equal_range` is for, so why not use it. Implementations of `std::equal_range` are likely do to things as efficiently as possible. Unfortunately, because `cooked_index_entry::compare` is sensitive to the order of its parameters, we need to provide two different comparison functions (just like we do know, to the lower_bound and upper_bound calls). But I think that the use of equal_range makes it clear what the intent of the code is. Regression tested using the various DWARF target boards on Debian 12. Change-Id: Idfad812fb9abae1b942d81ad9976aeed7c2cf762 Approved-By: Tom Tromey <tom@tromey.com>
2025-03-25gdb/dwarf: remove unnecessary comparison in cooked_index_entry::compareSimon Marchi1-5/+2
I believe that the `(mode == MATCH && a == munge ('<'))` part of the condition is unnecesary. Or perhaps I don't understand the algorithm. The use of "munge" above effectively makes it so that the template portion of names is completely ignored for the sake of the comparison. Then, in the condition, this: a == munge ('<') is functionally equivalent to a == '\0' If `a` is indeed '\0', and `b` is also '\0', then we would have taken the earlier branch: if (a == b) return 0; If `b` is not '\0', then we won't take this branch and we'll go into the final comparison: return a < b ? -1 : 1; So, as far as I can see, there is no case where `mode == MATCH`, where we're going to use this special `return 0`. Regression tested using the various DWARF target boards on Debian 12. Change-Id: I5ea0463c1fdbbc1b003de2f0a423fd0073cc9dec Approved-By: Tom Tromey <tom@tromey.com>
generated by cgit v1.1 at 2025-07-16 16:19:17 +0000