gprofng: Refactor readSymSec for using BFD's asymbol struct
This patch refactors a number of gprofng internal functions for using
more BFD data types and functions.
Stabs::readSymSec is a function which reads the symbols of an ELF file
mapping them into an internal structure. To use BFD asymbols, the
Elf::elf_getsym is changed from custom reading of the symbols from
.symtab and .dynsym section to BFD enable functions. A new function is
introduced which returns the number of either static or dynamic symbols,
named Elf::elf_getSymCount. Both Elf functions are used by
Stabs::readSymSec refactoring.
Also, this patch removes reading symbols, SUNW_ldnsym section as it is
only used by now defunct Studio compiler. However, it adds the reading
of both static and dynamic symbols, previously, only either one was
processed.
gdbserver: regcache: Update comment in supply_regblock
Since commit 84da4a1ea0ae ("gdbserver: refactor the definition and uses of
supply_regblock") there is no case where supply_regblock is passed a
nullptr for the BUF argument, and there is even a gdb_assert to make
sure of it.
Therefore remove that part of the documentation comment.
Jan Beulich [Fri, 4 Apr 2025 08:25:16 +0000 (10:25 +0200)]
binutils: run objcopy set-section-alignment also for COFF
There's no reason to limit this to just ELF. TI C30 and Z8k don't encode
section alignment in the section entries though (which can't be quite
right, or there would need to be another means by which to express
alignment needs), so --set-section-alignment simply has no effect there.
Jan Beulich [Fri, 4 Apr 2025 08:24:56 +0000 (10:24 +0200)]
objcopy: constrain --section-alignment to PE binaries again
PR binutils/32732
The --set-section-alignment option is what ought to be used on object
files; --section-alignment should be affecting PE binaries only, and
only the value stored in the header. Sections don't individually have
alignment recorded there; see 6f8f6017a0c4 ("PR27567, Linking PE files
adds alignment section flags to executables").
Undo the core part of 121a3f4b4f4a ("Update objcopy's
--section-alignment option so that it sets the alignment flag on..."),
which includes removing the testcase again, while leaving all secondary
changes in place. (Note that the testcase did fail anyway for
i?86-interix, with objdump saying "option -P/--private not supported by
this file".)
Jan Beulich [Fri, 4 Apr 2025 08:20:31 +0000 (10:20 +0200)]
ar/objcopy: harmonize .exe suffix stripping
With it only being the tail of the name which wants checking, using
lbasename() isn't helpful. Mirror what objcopy.c:main() does to ar.c,
merely chaning the plain int of the local variable to size_t.
Tom Tromey [Thu, 3 Apr 2025 18:11:15 +0000 (12:11 -0600)]
Make gdb/guile codespell-clean
This cleans up the last codespell reports in the Guile directory and
adds gdb/guile to pre-commit.
It also tells codespell to ignore URLs. I think this is warranted
because many URLs don't really contain words per se; and furthermore
if any URL-checking is needed at all, it would be for liveness and not
spelling.
Also I was wondering why the codespell config is in contrib and not
gdb/setup.cfg.
Tom Tromey [Thu, 3 Apr 2025 14:33:58 +0000 (08:33 -0600)]
Many minor typo fixes
I ran codespell on gdb/*.[chyl] and fixed a bunch of simple typos.
Most of what remains is trickier, i.e., spots where a somewhat natural
name of something in the code is flagged as a typo.
Tom de Vries [Thu, 3 Apr 2025 15:13:12 +0000 (17:13 +0200)]
[gdb/testsuite] Fix xfail in gdb.ada/array_of_variant.exp
In commit af2b87e649b ("[gdb/testsuite] Add xfail for PR gcc/101633"), I added
an xfail that was controlled by variable old_gcc, triggering the xfail for
gcc 7 and before, but not for gcc 8 onwards:
...
set old_gcc [expr [test_compiler_info {gcc-[0-7]-*}]]
...
In commit 1411185a57e ("Introduce and use gnat_version_compare"), this changed
to:
...
set old_gcc [gnat_version_compare <= 7]
...
which still triggered the xfail for gcc 7, because of a bug in
gnat_version_compare.
After that bug got fixed, the xfail was no longer triggered because the gnatmake
version is 7.5.0, and [version_compare {7 5 0} <= {7}] == 0.
We could have the semantics for version_compare where we clip the input
arguments to the length of the shortest, and so we'd have
[version_compare {7 5 0} <= {7}] == [version_compare {7} <= {7}] == 1.
But let's stick with the current version-sort semantics, and fix this by
using [gnat_version_compare < 8] instead.
Add a test-case gdb.testsuite/version-compare.exp that excercises proc
version_compare, and a note to proc version_compare that it considers
v1 < v1.0 instead of v1 == v1.0.
Tom Tromey [Mon, 17 Mar 2025 18:57:34 +0000 (12:57 -0600)]
Fix pp.rs test for gccrs
gccrs still can't process all of gdb's Rust tests, but I did manage to
manually test it on a few. In addition to filing some bug reports, I
came up with this patch.
There are two fixes here. First, gccrs emits tuple field names as
integers ("0", "1", etc) whereas rustc uses a leading double
underscore ("__0", "__1", etc). This patch changes gdb to accept the
gccrs output, which IMO makes sense (and for which there's already a
rustc feature request).
Second, it changes rust_struct_anon::evaluate to use check_typedef.
This is a gdb necessity in general, so could be described as an
oversight; but in this case it works around the gccrs oddity that most
named types are emitted as DW_TAG_typedef. I've filed a gccrs bug
report for that.
Tom Tromey [Fri, 28 Mar 2025 16:26:36 +0000 (10:26 -0600)]
Clean up cooked_index::done_reading
The cooked index worker maintains the state for the various state
transition in the scanner. It is held by the cooked_index while
scanning is in progress, then deleted once this has completed.
I noticed that none of the arguments to cooked_index::done_reading
were really needed -- the cooked_index already has access to the
worker should it need it. Removing these parameters makes the code a
bit simpler and also cleans up some confusing code around the use of
the deferred warnings object.
Regression tested on x86-64 Fedora 40.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Tue, 1 Apr 2025 18:30:33 +0000 (12:30 -0600)]
Update copyright.py
copyright.py needed an addition for unordered_dense.h.
Then, when running it, I saw it complain about some .pyc files I had
in the source tree. I don't know why I had these, but the script
should ignore them.
For this, Kévin suggested using "git ls-files" to determine which
files to update -- that should automatically exclude any random files
in the tree. This version of the patch makes this change.
There were complaints about some sim/ppc files that were renamed.
Ignoring the entire directory seems simpler given the comment.
I also made a few more minor changes:
* Removed the 'CVS' exclusion, as this hasn't been relevant in years.
* Moved the 'copying.c' exclusion to EXCLUDE_LIST
* Changed the script to run from the top level (we could have it
automatically find this if we really wanted).
After this lands, I plan to run it and check in the result. The patch
may be too large (and certainly too uninteresting) to post, so if/when
this happens I will send a brief note to the list about it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Luis Machado [Fri, 28 Feb 2025 09:36:42 +0000 (09:36 +0000)]
Fix gdbserver crashes on SVE/SME-enabled systems
Commit 51e6b8cfd649013ae16a3d00f1451b2531ba6bc9 fixed a
regression for SVE/SME registers on gdb's side by using a <= comparison for
regcache's raw_compare assertion check. We seem to have failed to do the same
for gdbserver's raw_compare counterpart.
With the code as it is, I'm seeing a lot of crashes for gdbserver on a machine
with SVE enabled. For instance, with the following invocation:
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" TESTS=gdb.base/break.exp
Running /work/builds/binutils-gdb/gdb/testsuite/../../../../repos/binutils-gdb/gdb/testsuite/gdb.base/break.exp ...
FAIL: gdb.base/break.exp: test_break: run until function breakpoint
FAIL: gdb.base/break.exp: test_break: run until breakpoint set at a line number (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(6) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(5) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(4) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(3) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(2) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(1) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until quoted breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:linenum breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: breakpoint offset +1
FAIL: gdb.base/break.exp: test_break: step onto breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: setting breakpoint at }
FAIL: gdb.base/break.exp: test_break: continue to breakpoint at } (the program is no longer running)
FAIL: gdb.base/break.exp: test_no_break_on_catchpoint: runto: run to main
FAIL: gdb.base/break.exp: test_break_nonexistent_line: runto: run to main
FAIL: gdb.base/break.exp: test_break_default: runto: run to main
FAIL: gdb.base/break.exp: test_break_silent_and_more: runto: run to main
FAIL: gdb.base/break.exp: test_break_line_convenience_var: runto: run to main
FAIL: gdb.base/break.exp: test_break_user_call: runto: run to main
FAIL: gdb.base/break.exp: test_finish_arguments: runto: run to main
FAIL: gdb.base/break.exp: test_next_with_recursion: kill program
FAIL: gdb.base/break.exp: test_next_with_recursion: run to factorial(6)
FAIL: gdb.base/break.exp: test_next_with_recursion: continue to factorial(5) (the program is no longer running)
FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5)
FAIL: gdb.base/break.exp: test_next_with_recursion: next to recursive call (the program is no longer running)
FAIL: gdb.base/break.exp: test_next_with_recursion: next over recursive call (the program is no longer running)
FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5.1)
FAIL: gdb.base/break.exp: test_next_with_recursion: continue until exit at recursive next test (the program is no longer running)
FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until function breakpoint, optimized file
FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until breakpoint set at small function, optimized file (the program is no longer running)
FAIL: gdb.base/break.exp: test_rbreak_shlib: rbreak junk
Adjusting the regcache raw_compare assertion check to use <= fixes
the problem on aarch64-linux on a SVE-capable system.
This patch also adds a simple selftest to gdbserver that validates this
particular case by simulating a raw_compare operation.
Compile a 32-bit x86 executable and then stop within a system call.
Change the sysroot to a non-existent directory, GDB should try (and
fail) to reload the currently loaded shared libraries. However, GDB
should retain the symbols for the vDSO library as that is not loaded
from the file system.
Check the backtrace to ensure that the __kernel_vsyscall symbol is
still in the backtrace, this indicates GDB still has the vDSO
symbols available.
Simon Marchi [Mon, 31 Mar 2025 20:09:42 +0000 (16:09 -0400)]
gdb: move addrmap::relocate method to addrmap_fixed
The relocate method of addrmap is unnecessarily virtual. Only
addrmap_fixed provides a meaningful implementation. Move the method to
addrmap_fixed only and make it non-virtual.
Change-Id: If61d5e70abc12c17d1e600adf0dd0707e77a6ba2 Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Tue, 1 Apr 2025 13:47:55 +0000 (15:47 +0200)]
[gdb/contrib] Support gdb in codespell section of setup.cfg
Add support for the gdb dir in the codespell section of gdb/contrib/setup.cfg,
specifically adding files in the skip line.
This allows us to run codespell from the command line on the gdb dir:
...
$ codespell --config gdb/contrib/setup.cfg gdb 2>/dev/null | wc -l
1665
...
without running into warnings in generated files.
Tom Tromey [Tue, 25 Mar 2025 13:17:38 +0000 (07:17 -0600)]
Remove cooked_index_worker::result_type
cooked_index_worker::result_type is an ad hoc tuple type used for
transferring data between phases of the indexer. It's a bit unwieldy
and another patch I'm working on would be somewhat nicer without it.
This patch removes the type. Now cooked_index_ephemeral objects are
transferred instead, which is handy because they already hold the
needed state.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Tue, 25 Mar 2025 19:25:39 +0000 (13:25 -0600)]
Add addrmap_mutable::clear
It was convenient to add a 'clear' method to addrmap_mutable. The
cleanest way to do this was to change the class to lazily initialize
its 'tree' member. This also makes addrmap_mutable::operator= a bit
less weird.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Mon, 24 Mar 2025 21:30:07 +0000 (15:30 -0600)]
Change includes in cooked-index-worker.h
This changes cooked-index-worker.h to include the new header files.
This breaks the circular dependency that would otherwise be introduced
in the next patch.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Mon, 24 Mar 2025 21:19:20 +0000 (15:19 -0600)]
Move cooked_index_shard to new files
This moves cooked_index_shard to a couple of new files,
dwarf2/cooked-index-shard.[ch]. The rationale is the same as the
previous patch: cooked-index.h had to be split to enable other
cleanups.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Mon, 24 Mar 2025 21:11:02 +0000 (15:11 -0600)]
Move cooked_index_entry to new files
This moves cooked_index_entry and some related helper code to a couple
of new files, dwarf2/cooked-index-entry.[ch].
The main rationale for this is that in order to finish this series and
remove "cooked_index_worker::result_type", I had to split
cooked-index.h into multiple parts to avoid circular includes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Mon, 24 Mar 2025 21:03:04 +0000 (15:03 -0600)]
Rename cooked-index-storage.[ch]
A discussion with Simon made me realize that cooked_index_storage
isn't a very clear name, especially now that it's escaped from read.c.
While it does provide some storage (I guess any object does in a
sense), it is really a helper for cooked_index_worker -- a temporary
object that is destroyed after reading has completed.
This patch renames this file. Later patches will rename the class and
move cooked_index_worker here, something I think is reasonable given
that cooked_index_storage is really something of a helper class for
cooked_index_worker.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Mon, 31 Mar 2025 08:49:28 +0000 (19:19 +1030)]
ubsan: nds32 undefined shift
Avoid implementation defined behaviour right shift of negative values,
and undefined behaviour left shift of negative values. While this
change might give different results in the top bit of a bfd_vma
(rightshift is 1), that doesn't matter as only the bottom 8 bits of
the relocation are used.
* elf32-nds32.c (nds32_elf_do_9_pcrel_reloc): Calculate relocation
using a bfd_vma type.
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
Tom de Vries [Mon, 31 Mar 2025 18:30:48 +0000 (20:30 +0200)]
[gdb/record] Make enum gdb_syscall value names consistent
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>
Lancelot SIX [Mon, 31 Mar 2025 11:06:06 +0000 (12:06 +0100)]
gdbsupport/common-inferior.c: Fix mingw build
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>
Tom de Vries [Mon, 31 Mar 2025 07:30:00 +0000 (09:30 +0200)]
[pre-commit] Add codespell hook
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
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.
Tom de Vries [Sun, 30 Mar 2025 06:40:12 +0000 (08:40 +0200)]
[gdb] Skip selftest with warning
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.
Andrew Burgess [Fri, 6 Sep 2024 15:18:09 +0000 (16:18 +0100)]
gdb: remove disable_breakpoints_in_shlibs function
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:
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.
H.J. Lu [Sat, 22 Mar 2025 15:14:40 +0000 (08:14 -0700)]
x86: Add {noimm8s} pseudo prefix
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.
Andrew Burgess [Sat, 7 Sep 2024 12:45:40 +0000 (13:45 +0100)]
gdb: reduce breakpoint-modified events for dprintf b/p
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.
Keith Seitz [Thu, 27 Mar 2025 15:46:39 +0000 (08:46 -0700)]
Fix gstack issues
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].
Jens Remus [Fri, 28 Mar 2025 14:27:11 +0000 (15:27 +0100)]
x86: Pass $NOPIE_LDFLAGS to undefined weak tests
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.
Jens Remus [Fri, 28 Mar 2025 14:27:11 +0000 (15:27 +0100)]
ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to more ELF visibility tests
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.
Jens Remus [Fri, 28 Mar 2025 14:27:11 +0000 (15:27 +0100)]
ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to even more ELF shared tests
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>
Jens Remus [Fri, 28 Mar 2025 14:27:11 +0000 (15:27 +0100)]
ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr21964-4
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.
Jens Remus [Fri, 28 Mar 2025 14:27:10 +0000 (15:27 +0100)]
ld: Pass $NOPIE_CFLAGS and $NOPIE_LDFLAGS to test pr19719
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.
Marek Pikuła [Thu, 27 Mar 2025 14:09:15 +0000 (15:09 +0100)]
RISC-V: Don't show support for 1.9.1 priv spec
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>
Marek Pikuła [Thu, 27 Mar 2025 14:09:14 +0000 (15:09 +0100)]
doc/riscv: Add description of disassembler options
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>
Craig Blackmore [Thu, 13 Feb 2025 15:53:34 +0000 (15:53 +0000)]
gdb: Fix assertion failure when inline frame #0 is duplicated
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>
Tom de Vries [Thu, 27 Mar 2025 16:53:52 +0000 (17:53 +0100)]
[gdb/contrib] Drop two words from codespell-ignore-words.txt
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
Tom de Vries [Thu, 27 Mar 2025 13:20:04 +0000 (14:20 +0100)]
[gdb/contrib] Add SME to codespell-ignore-words.txt
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.
oltolm [Fri, 28 Feb 2025 18:57:39 +0000 (19:57 +0100)]
gdb/dap - Add CompletionsRequest
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>
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.
Haochen Jiang [Wed, 19 Mar 2025 08:52:35 +0000 (16:52 +0800)]
x86: Remove AVX10.2 256 bit rounding support
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.
gdb/testsuite: Force DWARF debuginfo where applicable in AIX systems
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.
Jens Remus [Fri, 21 Mar 2025 14:29:03 +0000 (15:29 +0100)]
ld: Correct test pr19719 naming mix-up
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.
Guinevere Larsen [Thu, 13 Feb 2025 20:18:18 +0000 (17:18 -0300)]
gdb: add configure option to disable compile
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>
Guinevere Larsen [Thu, 13 Feb 2025 16:32:25 +0000 (13:32 -0300)]
gdb: Remove compile-related attributes from struct language
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.
Simon Marchi [Tue, 25 Mar 2025 20:32:21 +0000 (16:32 -0400)]
gdb/dwarf: use reference in cutu_reader::cutu_reader interface
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>
Simon Marchi [Tue, 25 Mar 2025 20:32:20 +0000 (16:32 -0400)]
gdb/dwarf: update comment of cutu_reader::cutu_reader (the DWO variant)
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>
Simon Marchi [Tue, 25 Mar 2025 20:32:19 +0000 (16:32 -0400)]
gdb/dwarf: remove redundant read of dwo_name
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>
WANG Xuerui [Mon, 24 Mar 2025 07:54:25 +0000 (15:54 +0800)]
LoongArch: Fix disassembly option parsing stopping at the first option
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.
Roland McGrath [Fri, 21 Mar 2025 02:17:20 +0000 (19:17 -0700)]
ld: Support RELRO in aarch64-elf target
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.
projects / thirdparty / binutils-gdb.git / log
