R_X86_64_TPOFF32 relocation of local-exec TLS model can only be used in
executable, not in a shared library, even if the source code is compiled
with -fPIC. Change the linker error message from
relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; recompile with -fPIC
to
relocation R_X86_64_TPOFF32 against symbol `foo' can not be used when making a shared object; replace local-exec with initial-exec TLS model
bfd/
PR ld/33408
* elf64-x86-64.c (elf_x86_64_need_pic): Suggest "replace
local-exec with initial-exec TLS model" for R_X86_64_TPOFF32.
(elf_x86_64_scan_relocs): Drop ABI_64_P check for
R_X86_64_TPOFF32.
Matthieu Longo [Thu, 4 Sep 2025 14:25:21 +0000 (15:25 +0100)]
ld: fix segfault when linker script is not found
ld previously crashed with a segmentation fault if the specified linker
script could not be found. The issue seems to have been introduced
recently by d048eee2910 [1].
This patch adds a check to ensure that a filename was found after
searching the possible prefixes. If no filename was found, the function
returns NULL, and ldfile_open_command_file_1() emits a proper fatal
error message.
This change prevents the crash and provides a clear diagnostic.
A new generic test was also added to cover this error case.
Tom Tromey [Sat, 23 Aug 2025 17:51:03 +0000 (11:51 -0600)]
Change type_stack::insert to take gdbarch
This changes type_stack::insert to take a gdbarch rather than an
expr_builder. This is simpler and means that type_stack doesn't have
to know anything about expression building; the parser-defs.h include
can be removed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sat, 23 Aug 2025 17:46:48 +0000 (11:46 -0600)]
Make type_stack popping a bit safer
This changes type_stack so that an element that has an argument can't
be popped in isolation. The idea is to make type stack use a little
safer, making it so that the stack can't end up in an invalid state.
This also fixes up a few related comments.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sat, 23 Aug 2025 17:39:35 +0000 (11:39 -0600)]
Make type_stack pushing a bit safer
This changes type_stack to make pushing elements a bit safer: if an
element requires an argument, these are now always pushed at the same
time, rather than separately.
This patch also adds a few comments to help document a bit better.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Tue, 9 Sep 2025 10:45:44 +0000 (20:15 +0930)]
readelf: tidy dump_relr_relocations
A comment in display_relocations said "RELRS has been freed by
dump_relr_relocations". Except that hadn't happened on all return
paths. Tidy that by freeing relrs allocated in dump_relr_relocations
in that function, and relrs allocated in display_relocation in that
function.
* readelf.c (dump_relr_relocations): Only free relrs allocated
in this function.
(display_relocations): Free relrs here, on error return paths
too.
Tom Tromey [Mon, 4 Aug 2025 16:39:02 +0000 (10:39 -0600)]
Use gnulib c-ctype module in gdb
PR ada/33217 points out that gdb incorrectly calls the <ctype.h>
functions. In particular, gdb feels free to pass a 'char' like:
char *str = ...;
... isdigit (*str)
This is incorrect as isdigit only accepts EOF and values that can be
represented as 'unsigned char' -- that is, a cast is needed here to
avoid undefined behavior when 'char' is signed and a character in the
string might be sign-extended. (As an aside, I think this API seems
obviously bad, but unfortunately this is what the standard says, and
some systems check this.)
Rather than adding casts everywhere, this changes all the code in gdb
that uses any <ctype.h> API to instead call the corresponding c-ctype
function.
Now, c-ctype has some limitations compared to <ctype.h>. It works as
if the C locale is in effect, so in theory some non-ASCII characters
may be misclassified. This would only affect a subset of character
sets, though, and in most places I think ASCII is sufficient -- for
example the many places in gdb that check for whitespace.
Furthermore, in practice most users are using UTF-8-based locales,
where these functions aren't really informative for non-ASCII
characters anyway; see the existing workarounds in gdb/c-support.h.
Note that safe-ctype.h cannot be used because it causes conflicts with
readline.h. And, we canot poison the <ctype.h> identifiers as this
provokes errors from some libstdc++ headers.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217 Approved-By: Simon Marchi <simon.marchi@efficios.com>
The upstream build of GDB can fail on fedora rawhide, since the self
check in regcache.c uses an unitialized variable to be compared, which
now generates the following warning:
binutils-gdb/gdb/regcache.c:1847:42: error: variable
'buf' is uninitialized when passed as a const pointer argument here
[-Werror,-Wuninitialized-const-pointer]
1847 | SELF_CHECK (regcache->raw_compare (0, &buf, register_size (inf.arch (), 0)));
This commit fixes that by initializing the variable to 0.
Since the comment above that line would be changed, it was also
reformatted so that it doesn't go beyond 80 columns.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
nm: fix treating an ifunc symbol as a stab if '--ifunc-chars=--' is given
If an ifunc symbol is processed in print_symbol(), a 'type' field of a
'syminfo' structure is set to any character specified by a user with an
'--ifunc-chars' option. But afterwards the 'type' field is used to
check whether a symbol is a stab in print_symbol_info_{bsd,sysv}()
functions in order to print additional stab related data. If the 'type'
field equals '-', a symbol is treated as a stab. If '--ifunc-chars=--'
is given, all ifunc symbols will be treated as stab symbols and
uninitialized stab related fields of the 'syminfo' structure will be
printed which can lead to segmentation fault.
To fix this, check if a symbol is a stab before override the 'type'
field. Also, add a test case for this fix.
PR binutils/32556
* nm.c (extended_symbol_info): Add is_stab.
(print_symbol): Check if a symbol is a stab.
(print_symbol_info_bsd): Use info->is_stab.
(print_symbol_info_sysv): Use info->is_stab.
* testsuite/binutils-all/nm.exp: Test nm --ifunc-chars=--.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32556 Fixes: e6f6aa8d184 ("Add option to nm to change the characters displayed for ifunc symbols") Signed-off-by: Dmitry Klochkov <dmitry.klochkov@bell-sw.com>
Nick Clifton [Tue, 9 Sep 2025 07:57:38 +0000 (08:57 +0100)]
objcopy: when an invalid bfd target string is used as a target option, print an error message that references the target string, not the file being copied
Tom Tromey [Sat, 6 Sep 2025 19:17:18 +0000 (13:17 -0600)]
Add m_builder member to lnp_state_machine
I noticed that several spots in lnp_state_machine fetch the CU's
builder. Since this can't change over the lifetime of the object, it
seemed nicer to simply cache it.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sat, 6 Sep 2025 18:16:26 +0000 (12:16 -0600)]
Move compute_include_file_name earlier
I noticed that the compute_include_file_name intro comment was
slightly wrong, and while looking at this, I also noticed that it has
a single caller. This patch hoists it slightly so that a forward
declaration isn't needed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sat, 6 Sep 2025 17:56:40 +0000 (11:56 -0600)]
Move lnp_state_machine to new file
This patch moves lnp_state_machine and some supporting code to a new
file, dwarf2/line-program.c. The main benefit of this is shrinking
dwarf2/read.c a bit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sun, 17 Aug 2025 17:38:15 +0000 (11:38 -0600)]
Use type-specific lookups in cp-support.c
cp-support.c has code to substitute types for typedef names when
canonicalizing a C++ name. I believe this code can use type-specific
search domains; and doing this greatly speeds up some cases.
Tom Tromey [Sat, 16 Aug 2025 18:21:15 +0000 (12:21 -0600)]
Avoid symbol lookup for field names in C parser
Currently, the C parser looks up any name it finds -- at lex time.
However, in an expression like "obj->field", looking up the field name
is wasteful, and can sometimes even yield pathological symtab
expansion behavior.
This patch arranges to avoid the name lookup in this case. (It would
be nice to really clean up this area, but I'm not convinced it can
readily be done in a yacc parser.)
Some special code is required for the C++ construct where a qualified
name is used, like "obj->type1::type2::field".
Tom Tromey [Tue, 5 Aug 2025 23:32:55 +0000 (17:32 -0600)]
Change how C parser looks up type tag names
In an earlier version of this series, Simon noticed that something
like "ptype struct type" was much slower.
The deep problem here is the hack in best_symbol -- in this particular
case the C parser is including SEARCH_VAR_DOMAIN, which means that a
type is not "best".
Fixing best_symbol would be good to do, but it's difficult and I
already had many struggles getting this series to this point. So,
rather than fix that, I elected to modify the parser.
The key insight here is that the name lookup in classify_name is
useless when a tag name is expected. This patch adds a flag so that
this lookup is not done. (Incidentally, this kind of thing is much
more straightforward in a recursive descent parser, something like
classify_name would only be applied post-lexing where appropriate.)
This change speeds up the lookup by avoiding the best_symbol hack,
instead searching only for a type.
Acked-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
gdb: Add svr4-tls-tdep.o to list of objects of i*86 targets
GDB currently fails to build from source on i386 if compiled with
--enable-64-bit-bfd. This is happening because svr4-tls-tdep.o is
missing from the gdb_target_obs variable, while amd64-linux-tdep.o is
obviously there.
Fix the problem by adding svr4-tls-tdep.o to the object list, but only
when --enable-64-bit-bfd is provided.
Tom Tromey [Mon, 28 Jul 2025 16:06:00 +0000 (10:06 -0600)]
Require Tcl 8.6.2
This changes the gdb test suite to require Tcl 8.6.2. This allows the
removal of some more compatibility code.
I wrote this as a separate patch so make it simpler to drop if some
platform only provides Tcl 8.5. According to research in the bug,
though, it seems like this isn't likely.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33205 Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Sun, 7 Sep 2025 23:07:13 +0000 (08:37 +0930)]
vms-alpha: ehdr checks
I noticed that _bfd_vms_slurp_ehdr wrongly used buf_size (rather than
rec_size) when sanity checking.
* vms-alpha.c (_bfd_vms_slurp_ehdr): Don't allow access to
uninitialised buffer memory. Tidy code generally, using
remaining record length for sanity checks.
Alan Modra [Sun, 7 Sep 2025 22:33:14 +0000 (08:03 +0930)]
PR 33385 vms archives
Commit 5c4ce239a3ab "Tidy bfdio to consistenly use containing archive"
broke vms archive handling, which has some horrible hacks involving
use of a special iovec for archive elements. Modify the generic
archive handling code to not use the archive iovec when it differs
from the element iovec.
Also, various commits involving seek optimisation broke the vms
archive handling, which needs to see a rewind on an archive element.
* bfdio.c (bfd_read, bfd_write, bfd_tell, bfd_flush),
(bfd_stat, bfd_seek, bfd_mmap): Do not use the archive
bfd for IO when the archive and element iovec differ.
* plugin.c (bfd_plugin_open_input),
(bfd_plugin_close_file_descriptor): Likewise.
* vms-lib.c (vms_lib_bopen): Force bfd_seek to call iovec seek.
Alan Modra [Sun, 7 Sep 2025 23:00:56 +0000 (08:30 +0930)]
PR 33385 unsupported relocs
Commit 96d3b80f5498 changed a couple of reloc functions to return
false, and propagated the error. They previously did nothing, so
revert to that sad state.
Alan Modra [Sun, 7 Sep 2025 22:56:43 +0000 (08:26 +0930)]
PR 33385 DST handling
Commit 816995444667, a fix for a fuzzer testcase resulting in a buffer
overflow, broke reading of DST. DST is a special case where a first
pass over the section just sizes it.
Commit a3c0896d80d2, another buffer overflow fix, wrongly removed a
line incrementing DST record length.
* vms-alpha.c (image_write): Don't do bounds check for
sections in memory without contents.
(evax_bfd_print_dst): Add one to length.
Alan Modra [Sun, 7 Sep 2025 22:46:21 +0000 (08:16 +0930)]
PR 33385, Extended Image Header
This modifies some of the PR 21813 fixes, allowing for smaller EIHD.
Not knowing any better, I chose to use EIHD__C_LENGTH as the minimum
length.
include/
* vms/eihd.h (EIHD__C_LENGTH): Comment.
bfd/
* vms-alpha.c (_bfd_vms_slurp_eihd): Remove size check
duplicating that done by the caller of this function.
(alpha_vms_object_p): Allow smaller EIHD.
(evax_bfd_print_image): Likewise. Don't print fields past
the record size.
gdb, amd64: extend the amd64 prologue analyzer to skip register pushes
A gdb_test_multiple exits early when processing the results of a
'disassemble' command, without waiting for the prompt to be seen.
This can leave unhandled output in expect's input buffer, which will
then throw off the next test.
Update the gdb_test_multiple to wait for the prompt before declaring
the test passed.
After this I'm no longer seeing the above failure.
There should be no change in what is tested after this commit.
Jan Beulich [Mon, 8 Sep 2025 09:11:51 +0000 (11:11 +0200)]
x86: constrain and fix use of the "nojumps" .arch modifier
As said by the paragraph of the description that isn't modified here (a
few lines up), this was only ever supposed to be used with 16-bit
architectures. Actually enforcing this allows code in
md_estimate_size_before_relax() to move to a less frequently used code
path. (For backwards compatibility, keep accepting "jumps" also with 32-
or 64-bit architectures.)
Repeat the constraint also in the 2nd paragraph of the doc on this
subject. And while there also insert a missing insn in the related
i386-Jumps section.
Furthermore checking a global variable during late processing is wrong. We
need to record the state in the fragment, and use that rather than the
state of the variable at the end of parsing all input.
Seeing that there's no testing of the functionality at all, add a testcase
as well.
Adding i386_pe_big_vec vector to win64 targets fixes an issue where a
64-bit assembler on windows would fail to create bigobj files when
operating with 32-bit word size. E.g., before this change, with a
64-bit toolchain:
Although the above multilib compilation issue was the motivation for
this patch, this change has other positive consequences, such as
allowing the 64-bit windows build of objdump to disassemble
pe-bigobj-i386 format object files, etc.
H.J. Lu [Thu, 4 Sep 2025 13:57:06 +0000 (06:57 -0700)]
ld: Limit "readelf --got-contents" tests
Since "readelf --got-contents" tests use -melf_i386, -melf_x86_64 and
-melf32_x86_64 emulations, limit theses tests to linker supporting those
emulations, pass --rosegment to linker and output libgot-1-i386.so,
libgot-1-x64.so, libgot-1-x32.so.
PR ld/33350
* testsuite/ld-i386/binutils.exp: Limit tests to linker with
-melf_i386 support, pass --rosegment to linker and output
libgot-1-i386.so.
* testsuite/ld-x86-64/binutils.exp: Limit -melf_x86_64 tests to
linker with -melf_x86_64 support, limit -melf32_x86_64 tests
to linker with -melf32_x86_64 support, pass --rosegment to
linker and output libgot-1-x64.so/libgot-1-x32.so.
gdb: Add i386-gnu-tdep to the list of objects for x86_64-*-gnu*
When starting GDB on Hurd amd64, one will currently see the following
warning:
# gdb -q
gdb: warning: A handler for the OS ABI "GNU/Hurd" is not built into this configuration
of GDB. Attempting to continue with the default i386 settings.
(gdb)
This happens because, in gdb/configure.tgt, the "x86_64-*-gnu*" target
is not pulling in the i386-gnu-tdep.o object, which means that only
64-bit debugging is currently supported.
The fix here is to add i386-gnu-tdep.o to the gdb_target_obs for Hurd
amd64.
Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net> Suggested-by: Andrew Burgess <aburgess@redhat.com> Reported-by: Mark Wielaard <mark@klomp.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33377 Approved-by: Kevin Buettner <kevinb@redhat.com>
Tom Tromey [Fri, 5 Sep 2025 11:31:34 +0000 (05:31 -0600)]
Allow conversion of 128-bit integers to Python
Currently, trying to convert a 128-bit integer from a gdb.Value to a
Python integer will fail. This is surprising because Python uses
bigints internally.
The bug here is that valpy_long uses value_as_long, which fails for
anything wider than LONGEST. This patch fixes the problem by using
the recommended Python API.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33366 Approved-By: Simon Marchi <simon.marchi@efficios.com>
Revert the change in test-case gdb.base/foll-vfork.exp, which does
'set binfile $testfile'.
Tested on x86_64-linux.
The only modified test-case I was not able to test is
gdb.base/dtrace-probe.exp (filed PR testsuite/33379 about this). The change
in the test-case is trivial though.
H.J. Lu [Thu, 4 Sep 2025 13:05:33 +0000 (06:05 -0700)]
readelf: Handle 0 sh_entsize of GOT sections
Gold, lld and mold set sh_entsize to 0 on .got and .got.plt sections.
If sh_entsize of GOT sections is 0, assume 8 for ELFCLASS64 and 4 for
ELFCLASS32, except for x32 which uses 8.
#6 0x00000000005ffee0 in breakpoint_free_objfile (objfile=0x4064b30) at ../../src/gdb/breakpoint.c:14747
#7 0x0000000000c33ff2 in objfile::~objfile (this=0x4064b30, __in_chrg=<optimized out>) at ../../src/gdb/objfiles.c:478
#8 0x0000000000c38da6 in std::default_delete<objfile>::operator() (this=0x7ffc1a49d538, __ptr=0x4064b30) at /usr/include/c++/9/bits/unique_ptr.h:81
#9 0x0000000000c3782a in std::unique_ptr<objfile, std::default_delete<objfile> >::~unique_ptr (this=0x7ffc1a49d538, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/unique_ptr.h:292
#10 0x0000000000caf1bd in owning_intrusive_list<objfile, intrusive_base_node<objfile> >::erase (this=0x3790d68, i=...) at ../../src/gdb/../gdbsupport/owning_intrusive_list.h:111
#11 0x0000000000cacd0c in program_space::remove_objfile (this=0x3790c80, objfile=0x4064b30) at ../../src/gdb/progspace.c:192
#12 0x0000000000c33e1c in objfile::unlink (this=0x4064b30) at ../../src/gdb/objfiles.c:408
#13 0x0000000000c34fb9 in objfile_purge_solibs (pspace=0x3790c80) at ../../src/gdb/objfiles.c:729
#14 0x0000000000edf6f7 in no_shared_libraries (pspace=0x3790c80) at ../../src/gdb/solib.c:1359
#15 0x0000000000fb3f6c in target_pre_inferior () at ../../src/gdb/target.c:2466
#16 0x0000000000a724d7 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:390
#17 0x0000000000a72a97 in run_command (args=0x0, from_tty=0) at ../../src/gdb/infcmd.c:514
#18 0x00000000006bbb3d in do_simple_func (args=0x0, from_tty=0, c=0x39124b0) at ../../src/gdb/cli/cli-decode.c:95
#19 0x00000000006c1021 in cmd_func (cmd=0x39124b0, args=0x0, from_tty=0) at ../../src/gdb/cli/cli-decode.c:2827
The function breakpoint_free_objfile is being called when an objfile
representing a shared library is being unloaded ahead of the inferior
being restarted, the function is trying to remove references to
anything that could itself reference the objfile that is being
deleted.
The assert is making the claim that, for a bp_location, which has a
single address, the objfile of the symtab associated with the location
will be the same as the objfile associated with the section of the
location.
This seems reasonable to me now, as it did when I added the assert in
commit:
The bp_location::section is maintained, according to the comments in
breakpoint.h, to aid overlay debugging (is that even used any more),
and looking at the code, this does appear to be the case.
The problem in the above case arises when we are dealing with an ifunc
function. What happens is that we end up with a section from one
objfile, but a symtab from a different objfile.
This problem originates from minsym_found (in linespec.c). The user
asked for 'break gnu_ifunc' where 'gnu_ifunc' is an ifunc function.
What this means is that gnu_ifunc is actually a resolver function that
returns the address of the actual function to use.
In this particular test case, the resolver function is in a shared
library, and the actual function to use is in the main executable.
So, when GDB looks for 'gnu_ifunc' is finds the minimal_symbol with
that name, and spots that this has type mst_text_gnu_ifunc. GDB then
uses this to figure out the actual address of the function that will
be run.
GDB then creates the symtab_and_line using the _real_ address and the
symtab in which that address lies, in our case this will all be
related to the main executable objfile.
But, finally, in minsym_found, GDB fills in the symtab_and_line's
section field, and this is done using the section containing the
original minimal_symbol, which is from the shared library objfile.
The minimal symbol and section are then use to initialise the
bp_location object, and this is how we end up in, what I think, is an
unexpected state.
So what to do about this?
The symtab_and_line::msymbol field is _only_ set within minsym_found,
and is then _only_ used to initialise the bp_location::msymbol field.
The bp_location::msymbol field is _only_ used in the function
set_breakpoint_location_function, and we only really care about the
msymbol type, we check to see if it's an ifunc symbol or not. This
allows us to set the name of the function correctly.
The bp_location::section is used, as far as I can tell, extensively
for overlay handling. It would seem to me, that this section should
be the section containing the actual breakpoint address. If the
question we're asking is, is this breakpoint mapped in or not? Then
surely we need to ask about the section holding the breakpoint's
address, and not the section holding some other code (e.g. the
resolver function). In fact, in a memory constrained environment,
you'd expect the resolver functions to get mapped out pretty early on,
but while the actual functions might still be mapped in.
Finally, symtab_and_line::section. This is mostly set using calls to
find_pc_overlay. The minsym_found function is one of the few places
where we do things differently. In the places where the section is
used, it is (almost?) always used in conjunction with the
symtab_and_line::pc to lookup information, e.g. calls to
block_for_pc_sect, or find_pc_sect_containing_function. In all these
cases, it appears to me that the assumption is that the section will
be the section that contains the address.
So, where does this leave us?
I think what we need to do is update minsym_found to just use
find_pc_overlay, which is how the symtab_and_line::section is set in
most other cases. What this actually means in practise is that the
section field will be set to NULL (see find_pc_overlay in symfile.c).
But given that this is how the section is computed in most other
cases, I don't see why it should be especially problematic for this
case. In reality, I think this just means that the section is
calculated via a call to find_pc_section when it's needed, as an
example, see lookup_minimal_symbol_by_pc_section (minsyms.c).
I do wonder if we should be doing better when creating the
symtab_and_line, and insist that the section be calculated correctly
at that point, but I really don't want to open that can of worms right
now, so I think just changing minsym_found to "do it just like
everyone else" should be good enough.
I've extended the existing ifunc test to expose this issue, the
updated test fails without this patch, and passes with.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 27 Aug 2025 19:24:02 +0000 (20:24 +0100)]
gdb: pass core file to gdbarch_core_read_x86_xsave_layout
Continuing the removal of 'current_program_space->core_bfd ()' from
GDB, this commit updates the gdbarch method
'gdbarch_core_read_x86_xsave_layout' to take the core file BFD as a
reference parameter. For now this just moves the
'current_program_space->core_bfd ()' calls up the program stack into
core_target::fetch_x86_xsave_layout. In the future I plan to move the
core file BFD object out of the program_space and into the
core_target, at which point these new global accesses can also be
removed.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 27 Aug 2025 19:14:03 +0000 (20:14 +0100)]
gdb: pass core file to gdbarch_core_thread_name method
Continuing the removal of 'current_program_space->core_bfd ()' from
GDB, this commit updates the gdbarch method 'gdbarch_core_thread_name'
to take the core file BFD as a reference parameter. For now this just
moves the 'current_program_space->core_bfd ()' calls up the program
stack into core_target::thread_name. In the future I plan to move the
core file BFD object out of the program_space and into the
core_target, at which point these new global accesses can also be
removed.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
to take the core file BFD as a reference parameter. For now this just
moves the 'current_program_space->core_bfd ()' calls up the program
stack into core_target::xfer_partial. In the future I plan to move
the core file BFD object out of the program_space and into the
core_target, at which point these new global accesses can also be
removed.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Fri, 5 Sep 2025 07:54:41 +0000 (09:54 +0200)]
[gdb/testsuite] Fix gdb.base/fileio.exp for local-remote-host-native
When running test-case gdb.base/fileio.exp with host/target board
local-remote-host-native I run into:
...
gdb compile failed, fileio.c: In function 'test_open':
<command-line>:0:8: error: expected expression before '.' token
fileio.c:89:15: note: in expansion of macro 'OUTDIR'
ret = open (OUTDIR FILENAME, O_CREAT | O_TRUNC | O_RDWR, S_IWUSR | S_IRUSR);
^~~~~~
...
Fix this by using:
- quote_for_host to pass -DOUTDIR to the compilation, and
- STRINGIFY to stringify OUTDIR in fileio.c.
Tested on x86_64-linux, with target board unix and host/target board
local-remote-host-native.
Tom de Vries [Fri, 5 Sep 2025 06:37:30 +0000 (08:37 +0200)]
[gdb/testsuite] Fix silent timeout in allow_aarch64_gcs_tests
I noticed on M1 aarch64-linux that test-case
gdb.testsuite/gdb-caching-proc-consistency.exp took a long time.
I saw lack of progress in gdb.log for proc allow_aarch64_gcs_tests.
This gdb_expect only handles the case that gcs support is detected:
...
gdb_expect {
-re ".*$inferior_exited_re normally.*${gdb_prompt} $" {
verbose -log "\n$me: gcs support detected"
set allow_gcs_tests 1
}
}
...
but in my case, I get:
...
(gdb) run ^M
Starting program: allow_aarch64_gcs_tests.x ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
[Inferior 1 (process 3336556) exited with code 01]^M
(gdb)
...
so the gdb_expect times out quietly, taking 10 seconds.
In the test-case, it does so 11 times.
Fix this by adding a gdb_expect clause handling the "with code 01" case.
Jan Beulich [Fri, 5 Sep 2025 06:33:27 +0000 (08:33 +0200)]
x86: check reloc types for relaxable branches
Bypassing _reloc() isn't a good idea, as there are various errors
checked for there. For example 16-bit JMP or Jcc may not use the @plt
form (resulting in a 32-bit relocation to be emitted for a 16-bit
field), which so far we only reject for 16-bit CALL. In exchange this
allows simplifying the setting up of the "reloc_type" local variable.
Jan Beulich [Fri, 5 Sep 2025 06:32:25 +0000 (08:32 +0200)]
x86: make reloc() usable during late phases of assembly
Introduce a clone with extra parameters, to allow subsequent use from
md_estimate_size_before_relax() (or elsewhere, should that turn out
necessary). There flag_code cannot be used and location information
needs to be provided for diagnostics.
Andrew Burgess [Mon, 1 Sep 2025 16:00:15 +0000 (17:00 +0100)]
gdb/dap: check values are available before converting to int
In VariableReference.to_object, we try to convert a gdb.Value to an
int without checking if the value is actually available. This came to
light in PR gdb/33345, after the x86 CET shadow stack patches were
merged.
If the x86 CET shadow stack register is available on the machine,
but the shadow stack feature is not enabled at run time, then the
register will show as "<unavailable>".
As the register is of type 'void *', then in the DAP code we try to
add a 'memoryReference' attribute with the value of the register
formatted as hex. This will fail if the register is unavailable.
To test this change you'll need:
(a) a machine which support the shadow stack feature, and
(b) to revert the changes from commit 63b862be762e1e6e7 in the file
gdb.dap/scopes.exp.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345 Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Add a new gdb.Value.is_unavailable attribute. This is similar to the
existing Value.is_optimized_out attribute, but returns True if any
part of the value is <unavailable>.
The existing Value.is_optimized_out attribute returns true if any part
of the value is optimized out, so I thought that Value.is_unavailable
should work the same way.
Pawel Kupczak [Thu, 28 Aug 2025 11:50:15 +0000 (11:50 +0000)]
gdb, amd64: extend the amd64 prologue analyzer to skip stack alloc
Following the previous patch (gdb, amd64: extend the amd64 prologue
analyzer to skip register pushes), this patch extends the analyzer
further to be able to skip stack space allocation as the next prologue
part, for functions with a frame pointer. Implementation was based
on the i386 counterpart, which already had that functionality.
As of now, the stack allocation is not skipped. Examples below use C
source listed below, compiled with gcc 11.4.0.
```
int foo (int n)
{
int ns[] = { 1, 4, 9, 16, 25 };
return ns[n];
}
int
main (int argc, char **argv)
{
return foo (argc);
}
```
Compiling with "gcc -O0 -fno-omit-frame-pointer" we get:
```
(gdb) b foo
Breakpoint 1 at 0x1151
(gdb) r
...
Breakpoint 1, 0x0000555555555151 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555149 <+0>: endbr64
0x000055555555514d <+4>: push %rbp
0x000055555555514e <+5>: mov %rsp,%rbp
=> 0x0000555555555151 <+8>: sub $0x30,%rsp
0x0000555555555155 <+12>: mov %edi,-0x24(%rbp)
...
```
With this patch, it gets skipped the same way register pushes are:
```
(gdb) b foo
Breakpoint 1 at 0x1155
(gdb) r
...
Breakpoint 1, 0x0000555555555155 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555149 <+0>: endbr64
0x000055555555514d <+4>: push %rbp
0x000055555555514e <+5>: mov %rsp,%rbp
0x0000555555555151 <+8>: sub $0x30,%rsp
=> 0x0000555555555155 <+12>: mov %edi,-0x24(%rbp)
...
```
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Pawel Kupczak [Thu, 28 Aug 2025 11:50:13 +0000 (11:50 +0000)]
gdb, amd64: extend the amd64 prologue analyzer to skip register pushes
A typical function's prologue can consist of setting up a frame pointer,
pushing registers onto the stack and allocating space on the stack.
Current amd64 prologue analyzer would stop after the frame setup.
This patch allows GDB to skip past register pushes, while also improving
unwinding pushed registers, for functions with a frame pointer, without
debug info and .cfi directives found in .eh_frame section that are used
for unwinding. Skipping register pushes was also present for i386
targets before - the proposed changes are based on i386 implementation.
It also improves the unwinding even if .cfi directives are present,
because GDB can only unwind a register if it has reached a corresponding
.cfi directive, which won't be there before the pushes.
Additionally, at least gcc 11.4 and later by default doesn't emit
necessary debug info, which GDB would try to use to find prologue's end.
In that case, extended prologue analyzer would take effect.
Using C source listed below as an example, compiled with gcc 11.4.0:
```
int __attribute__ ((noinline))
bar (int a)
{
return a + a;
}
int __attribute__ ((noinline))
foo (int a, int b, int c, int d, int e)
{
int x = bar (a) + bar (b) + bar (c) + bar (d) + bar (e);
return x;
}
int
main (int argc, char **argv)
{
return foo (1, 2, 3, 4, 5);
}
```
Compiling with "gcc -O1 -fno-omit-frame-pointer
-fno-asynchronous-unwind-tables", we get:
```
(gdb) b foo
Breakpoint 1 at 0x1139
(gdb) r
...
Breakpoint 1, 0x0000555555555139 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555131 <+0>: endbr64
0x0000555555555135 <+4>: push %rbp
0x0000555555555136 <+5>: mov %rsp,%rbp
=> 0x0000555555555139 <+8>: push %r15
0x000055555555513b <+10>: push %r14
0x000055555555513d <+12>: push %r13
0x000055555555513f <+14>: push %r12
0x0000555555555141 <+16>: push %rbx
0x0000555555555142 <+17>: sub $0x8,%rsp
0x0000555555555146 <+21>: mov %esi,%r15d
...
(gdb) ni
0x000055555555513b in foo ()
(gdb) p $r15
$1 = 140737354125376
(gdb) p $r15=1234
$2 = 1234
(gdb) p $r15
$3 = 1234
(gdb) up
#1 0x00005555555551b7 in main ()
(gdb) p $r15
$4 = 1234
```
With the proposed changes, breakpoint gets past those register pushes:
```
(gdb) b foo
Breakpoint 1 at 0x1142
(gdb) r
...
Breakpoint 1, 0x0000555555555142 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555131 <+0>: endbr64
0x0000555555555135 <+4>: push %rbp
0x0000555555555136 <+5>: mov %rsp,%rbp
0x0000555555555139 <+8>: push %r15
0x000055555555513b <+10>: push %r14
0x000055555555513d <+12>: push %r13
0x000055555555513f <+14>: push %r12
0x0000555555555141 <+16>: push %rbx
=> 0x0000555555555142 <+17>: sub $0x8,%rsp
0x0000555555555146 <+21>: mov %esi,%r15d
...
```
Also, unwinding pushed registers now works:
```
...
Breakpoint 1, 0x0000555555555142 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555131 <+0>: endbr64
0x0000555555555135 <+4>: push %rbp
0x0000555555555136 <+5>: mov %rsp,%rbp
0x0000555555555139 <+8>: push %r15
0x0000555555555139 <+8>: push %r15
0x000055555555513b <+10>: push %r14
0x000055555555513d <+12>: push %r13
0x000055555555513f <+14>: push %r12
0x0000555555555141 <+16>: push %rbx
=> 0x0000555555555142 <+17>: sub $0x8,%rsp
0x0000555555555146 <+21>: mov %esi,%r15d
...
(gdb) p $r15
$1 = 140737354125376
(gdb) p $r15=1234
$2 = 1234
(gdb) p $r15
$3 = 1234
(gdb) up
#1 0x00005555555551b7 in main ()
(gdb) p $r15
$4 = 140737354125376
```
Additionally a new test was added to verify this behavior.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
I also considered changing gdbserver to not send Bss=, but decided
against this, reasoning that we may as well not break compatibility
with older versions of gdb.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33319 Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdb/testsuite: fix possible TCL errors in gdb.threads/threadcrash.exp
The test gdb.threads/threadcrash.exp, among other things, creates a list
of the threads seen in the order that the "thread apply all backtrace"
would generate them, tests that this list is the same size as GDB's
count of threads, and then loops over the list to check that each
thread has the expected backtrace.
A problem occurs because the loop iterates on GDB's internal count of
threads, rather than the size of the list, but then attempts to acces
the n-th element of the list. If the list size is smaller than GDB's
internal thread count, it'll access past the end of the list and
generate TCL errors.
This commit fixes this by using the list's length instead.
Andrew Burgess [Wed, 27 Aug 2025 18:40:30 +0000 (19:40 +0100)]
gdb: remove most global core file accesses from fbsd-tdep.c
This commit removes many places in fbsd-tdep.c where we access the
current core file via current_program_space, and replaces these
accesses with a function argument that is passed in.
There are still two uses of 'current_program_space->core_bfd ()' in
the file, these will be addressed in future work (not in this series
though).
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
projects / thirdparty / binutils-gdb.git / log
