Alan Modra [Mon, 14 Apr 2025 09:41:53 +0000 (19:11 +0930)]
windres: don't exit so much on errors in read_coff_rsrc
windres code has the habit of exiting on any error. That's not so
bad, but it does make oss-fuzz ineffective when testing windres. Fix
many places that print errors and exit to instead print the error and
pass status up the call chain. In the process of doing this, I
noticed write_res_file was calling bfd_close without checking return
status. Fixing that resulted in lots of testsuite failures. The
problem was a lack of bfd_set_format in windres_open_as_binary, which
leaves the output file as bfd_unknown format. As it happens this
doesn't make any difference in writing the output binary file, except
for the bfd_close return status.
Alan Modra [Mon, 14 Apr 2025 01:01:32 +0000 (10:31 +0930)]
windres: buffer overflow in bin_to_res_toolbar
oss-fuzz testcase manages to hit a buffer overflow. Sanity check
by passing the buffer length to bin_to_res_toolbar and ensuring reads
don't go off the end of the buffer.
Jan Beulich [Mon, 14 Apr 2025 12:24:28 +0000 (14:24 +0200)]
ld/PE: restrict non-zero default DLL characteristics to MinGW
While commit ef6379e16dd1 ("Set the default DLL chracteristics to 0 for
Cygwin based targets") tried to undo the too broad earlier 514b4e191d5f
("Change the default characteristics of DLLs built by the linker to more
secure settings"), it didn't go quite far enough. Apparently the
assumption was that if it's not MinGW, it must be Cygwin. Whether it
really is okay to default three of the flags to non-zero on MinGW also
remains unclear - sadly neither of the commits came with any description
whatsoever. (Documentation also wasn't updated to indicate the restored
default.)
Setting effectively any of the DLL characteristics flags depends on
properties of the binary being linked. While defaulting to "more secure"
is a fair goal, it's only the programmer who can know whether their code
is actually compatible with the respective settings. On the assumption
that the change of defaults was indeed deliberate (and justifiable) for
MinGW, limit them to just that. In particular, don't default any of the
flags to set also for non-MinGW, non-Cygwin targets, like e.g. UEFI. At
least the mere applicability of the high-entropy-VA bit is pretty
questionable there in the first place - UEFI applications, after all,
run in "physical mode", i.e. either unpaged or (where paging is a
requirement, like for x86-64) direct-mapped.
The situation is particularly problematic with NX-compat: Many UEFI
implementations respect the "physical mode" property, where permissions
can't be enforced anyway. Some, like reportedly OVMF, even have a build
option to behave either way. Hence successfully testing a UEFI binary on
any number of systems does not guarantee it won't crash elsewhere if the
flag is wrongly set.
Jan Beulich [Mon, 14 Apr 2025 12:23:53 +0000 (14:23 +0200)]
bfd/ELF/x86: avoid layering violation in link hash table entry init
There's no reason not to do as the comment says, just like all other
architectures do when they need custom field: Call the allocation method
of the "superclass". Which is the ELF one, of which in turn the BFD one
is the "superclass", dealt with accordingly by
_bfd_elf_link_hash_newfunc().
Jan Beulich [Mon, 14 Apr 2025 12:23:29 +0000 (14:23 +0200)]
bfd/aout: drop add_one_symbol() hook
The need for this has disappeared with c65c21e1ffd1 ("various i386-aout
and i386-coff target removal"), with a few other users having got
removed just a few days earlier; avoid the unnecessary indirection.
Jan Beulich [Mon, 14 Apr 2025 12:22:49 +0000 (14:22 +0200)]
bfd/COFF: propagate function size when copying/linking ELF objects
While COFF, unlike ELF, doesn't have a generic way to express symbol
size, there is a means to do so for functions. When inputs are ELF,
propagate function sizes, including the fact that a symbol denotes a
function, to the output's symbol table.
Note that this requires hackery (cross-object-format processing) in two
places - when linking, global symbols are entered into a global hash
table, and hence relevant information needs to be updated there in that
case, while otherwise the original symbol structures can be consulted.
For the setting of ->u.syment.n_type the later writing of the field to
literal 0 needs to be dropped from coff_write_alien_symbol(). It was
redundant anyway with an earlier write of the field using C_NUL.
Andrew Burgess [Sun, 13 Apr 2025 13:01:59 +0000 (14:01 +0100)]
gdb: add an assert to cmd_list_element constructor
The cmd_list_element::doc variable must be non-nullptr, otherwise, in
`help_cmd` (cli/cli-decode.c), we will trigger an assert when we run
one of these lines:
gdb_puts (c->doc, stream);
or,
gdb_puts (alias->doc, stream);
as gdb_puts requires that the first argument (the doc string) be
non-nullptr.
Better, I think, to assert when the cmd_list_element is created,
rather than catching an assert later when 'help CMD' is used.
I only ran into this case when messing with the Python API command
creation code, I accidentally created a command with a nullptr doc
string, and only found out when I ran 'help CMD' and got an
assertion.
While I'm adding this assertion, I figure I should also assert that
the command name is not nullptr too. Looking through cli-decode.c,
there seems to be plenty of places where we assume a non-nullptr name.
Built and tested on x86-64 GNU/Linux with an all-targets build; I
don't see any regressions, so (I hope) there are no commands that
currently violate this assertion.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
WANG Xuerui [Sun, 23 Mar 2025 09:30:38 +0000 (17:30 +0800)]
LoongArch: Support LA32R aliases rdcnt{vl,vh,id}.w
These LA32R instructions are in fact special cases of the LA32S/LA64
rdtime{l,h}.w (with only one output operand instead of two, the other
one being forced to $zero), but are named differently in the LA32R
ISA manual nevertheless.
As the LA32R names are more memorable to a degree (especially for those
having difficulties remembering which operand corresponds to the node
ID), support them by making them aliases of the corresponding LA32S/LA64
instruction respectively, and make them render as such in disassembly.
Andrew Burgess [Wed, 12 Mar 2025 11:16:42 +0000 (11:16 +0000)]
gdb: silence some 'Can't open file' warnings from core file loading
But PR gdb/20126 highlights a case where GDB emits a large number of
warnings like:
warning: Can't open file /anon_hugepage (deleted) during file-backed mapping note processing
warning: Can't open file /dev/shm/PostgreSQL.1150234652 during file-backed mapping note processing
warning: Can't open file /dev/shm/PostgreSQL.535700290 during file-backed mapping note processing
warning: Can't open file /SYSV604b7d00 (deleted) during file-backed mapping note processing
... etc ...
when opening a core file. This commit aims to avoid at least some of
these warnings.
What we know is that, for at least some of these cases, (e.g. the
'(deleted)' mappings), the content of the mapping will have been
written into the core file itself. As such, the fact that the file
isn't available ('/SYSV604b7d00' at least is a shared memory mapping),
isn't really relevant, GDB can still provide access to the mapping, by
reading the content from the core file itself.
What I propose is that, when processing the file backed mappings, if
all of the mappings for a file are covered by segments within the core
file itself, then there is no need to warn the user that the file
can't be opened again. The debug experience should be unchanged, as
GDB would have read from the in-core mapping anyway.
Andrew Burgess [Sun, 6 Apr 2025 20:52:50 +0000 (21:52 +0100)]
bfd: fix missing warnings from bfd_check_format_matches
In PR gdb/31846 the user reported an issue where GDB is unable to find
the build-id within an ELF, despite the build-id being
present (confirmed using readelf).
The user was able to try several different builds of GDB, and in one
build they observed the warning:
warning: BFD: FILENAME: unable to decompress section .debug_info
But in may other builds of GDB this warning was missing.
There are, I think, a couple of issues that the user is running into,
but this patch is about why the above warning is often missing from
GDB's output.
I wasn't able to reproduce a corrupted .debug_info section such that
the above warning would be triggered, but it is pretty easy to patch
the _bfd_elf_make_section_from_shdr function (in bfd/elf.c) such that
the call to bfd_init_section_decompress_status is reported as a
failure, thus triggering the warning. There is a patch that achieves
this in the bug report.
I did this, and can confirm that on my build of GDB, I don't see the
above warning, even though I can confirm that the _bfd_error_handler
call (in _bfd_elf_make_section_from_shdr) is being reached.
The problem is back in format.c, in bfd_check_format_matches. This
function intercepts all the warnings and places them into a
per_xvec_messages structure. These warnings are then printed with a
call to print_and_clear_messages.
If bfd_check_format_matches finds a single matching format, then
print_and_clear_messages, will print all warnings associated with that
single format.
But if no format matches, print_and_clear_messages will print all the
warnings, so long as all targets have emitted the same set of
warnings, and unfortunately, that is not the case for me.
The warnings are collected by iterating over bfd_target_vector and
trying each target. My target happens to be x86_64_elf64_vec, and, as
expected this target appears in bfd_target_vector.
However, bfd_target_vector also includes DEFAULT_VECTOR near the top.
And in my build, DEFAULT_VECTOR is x86_64_elf64_vec. Thus, for me,
the x86_64_elf64_vec entry appears twice in bfd_target_vector, this
means that x86_64_elf64_vec ends up being tried twice, and, as each
try generates one warning, the x86_64_elf64_vec entry in the
per_xvec_messages structure, has two warnings, while the other
per_xvec_messages entries only have one copy of the warning.
Because of this difference, print_and_clear_messages decides not to
print any of the warnings, which is not very helpful.
I considered a few different approaches to fix this issue:
We could de-duplicate warnings in the per_xvec_messages structure as
new entries are added. So for any particular xvec, each time a new
warning arrives, if the new warning is identical to an existing
warning, then don't record it. This might be an interesting change in
the future, but for now I rejected this solution as it felt like a
bodge, the duplicate warnings aren't really from a single attempt at
an xvec, but are from two distinct attempts at the same xvec. And so:
I wondered if we could remove the duplicate entries from
bfd_target_vector. Or if we could avoid processing the same xvec
twice maybe? For the single DEFAULT_VECTOR this wouldn't be too hard
to do, but bfd_target_vector also includes SELECT_VECS, which I think
could contain more duplicates. Changing bfd_check_format_matches to
avoid attempting any duplicate vectors would now require more
complexity than a single flag, and I felt there was an easier
solution, which was:
I propose that within bfd_check_format_matches, within the loop that
tries each entry from bfd_target_vector, as we switch to each vector
in turn, we should delete any existing warnings within the
per_xvec_messages structure for the target vector we are about to try.
This means that, if we repeat a target, only the last set of warnings
will survive.
With this change in place, print_and_clear_messages now sees the same
set of warnings for each target, and so prints out the warning
message.
Additionally, while I was investigating this issue I managed to call
print_and_clear_messages twice. This caused a crash because the first
call to print_and_clear_messages frees all the associated memory, but
leaves the per_xvec_messages::next field pointing to the now
deallocated object. I'd like to propose that we set the next field to
NULL in print_and_clear_messages. This clearly isn't needed so long
as print_and_clear_messages is only called once, but (personally) I
like to set pointers back to NULL if the object they are pointing to
is free and the parent object is going to live for some additional
time. I can drop this extra change if people don't like it.
This change doesn't really "fix" PR gdb/31846, but it does mean that
the warning about being unable to decompress .debug_info should now be
printed consistently, which is a good thing.
gdb/testsuite: fix gdb.base/dlmopen-ns-ids.exp racy test
The recently included gdb.base/dlmopen-ns-ids.exp test can sometimes
fail the call to get_integer_valueof when trying to check the namespace
ID of the fourth dlopened SO, for apparently no reason.
What's happening is that the call to get_first_so_ns doesn't necessarily
consume the GDB prompt, and so get_integer_valueof will see the prompt
immediately and not find the value the test is looking for.
To fix this, the test was changed so that we consume all of the output
of the command "info sharedlibrary", but only set the namespace ID for
the first occurrence of the SO we're looking for. The command now also
gets the solib name as a parameter, to reduce the amount of output.
Co-Authored-By: Tom de Vries <tdevries@suse.de> Approved-By: Tom de Vries <tdevries@suse.de>
skipped the LTO archive member even when the earlier item is also an
archive. Instead, skip the LTO archive member only if the earlier item
is a shared library.
bfd/
PR ld/32846
PR ld/32854
* elflink.c (elf_link_add_archive_symbols): Skip the LTO archive
member only if the earlier item is a shared library.
Tom de Vries [Thu, 10 Apr 2025 16:42:06 +0000 (18:42 +0200)]
[gdb/unittests] Ignore spellcheck warning in rsp-low-selftests.c
Ignore the following spellcheck warning:
...
$ codespell --config gdb/contrib/setup.cfg gdb/unittests
gdb/unittests/rsp-low-selftests.c:54: fo ==> of, for, to, do, go
...
and add gdb/unittests to the pre-commit codespell configuration.
Tom de Vries [Thu, 10 Apr 2025 02:50:26 +0000 (04:50 +0200)]
[gdb/testsuite] Fix gdb.dwarf2/fission-with-type-unit.exp with remote host
When running test-case gdb.dwarf2/fission-with-type-unit.exp with a remote
host configuration, say host board local-remote-host and target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) maint expand-symtabs^M
During symbol reading: Could not find DWO CU \
fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0x2d7 \
[in module /home/remote-host/fission-with-type-unit]^M
warning: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced \
by CU at offset 0x2d7 [in module /home/remote-host/fission-with-type-unit]^M
(gdb) FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs
...
Fix this by adding the missing download to remote host of the .dwo file.
Tested by running make-check-all.sh on x86_64-linux.
Simon Marchi [Tue, 8 Apr 2025 18:23:28 +0000 (14:23 -0400)]
gdbsupport: fix Makefile.in copyright dates
Commit d01e823438 ("Update copyright dates to include 2025") incorrectly
changed the dates in Makefile.in. Re-run `autoreconf` in the gdbsupport
directory to fix that up.
Simon Marchi [Tue, 8 Apr 2025 18:23:27 +0000 (14:23 -0400)]
sim: fix Makefile.in copyright dates
Commit d01e823438 ("Update copyright dates to include 2025") incorrectly
changed the dates in Makefile.in. Re-run `autoreconf` in the sim
directory to fix that up.
Simon Marchi [Tue, 8 Apr 2025 18:23:26 +0000 (14:23 -0400)]
gnulib: revert copyright date changes in imported files
Commit d01e823438 ("Update copyright dates to include 2025") changed the
dates in the gnulib imported source files, it probably shouldn't have.
Re-run update-gnulib.sh to restore those files.
gnulib/Makefile.in was also incorrectly modified, running the script
fixes that too.
Tom de Vries [Wed, 9 Apr 2025 10:10:10 +0000 (12:10 +0200)]
[gdb/testsuite] Allow thread exited message in gdb.threads/infcall-from-bp-cond-simple.exp
With a gdb 15.2 based package and test-case
gdb.threads/infcall-from-bp-cond-simple.exp, I ran into:
...
Thread 2 "infcall-from-bp" hit Breakpoint 3, function_with_breakpoint () at \
infcall-from-bp-cond-simple.c:51
51 return 1; /* Nested breakpoint. */
Error in testing condition for breakpoint 2:
The program being debugged stopped while in a function called from GDB.
Evaluation of the expression containing the function
(function_with_breakpoint) will be abandoned.
When the function is done executing, GDB will silently stop.
[Thread 0x7ffff73fe6c0 (LWP 951822) exited]
(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
run_bp_cond_hits_breakpoint: continue
...
The test fails because it doesn't expect the "[Thread ... exited]" message.
I have tried to reproduce this test failure, both using 15.2 and current
trunk, but haven't managed.
Regardless, I think the message is harmless, so allow it to occur, both in
run_bp_cond_segfaults and run_bp_cond_hits_breakpoint.
Tom de Vries [Wed, 9 Apr 2025 10:02:18 +0000 (12:02 +0200)]
[gdb/symtab] Handle DW_OP_entry_value at function entry
On riscv64-linux, with test-case gdb.base/vla-optimized-out.exp I ran into:
...
(gdb) p sizeof (a)^M
$2 = <optimized out>^M
(gdb) FAIL: $exp: o1: printed size of optimized out vla
...
The variable a has type 0xbf:
...
<1><bf>: Abbrev Number: 12 (DW_TAG_array_type)
<c0> DW_AT_type : <0xe3>
<c4> DW_AT_sibling : <0xdc>
<2><c8>: Abbrev Number: 13 (DW_TAG_subrange_type)
<c9> DW_AT_type : <0xdc>
<cd> DW_AT_upper_bound : 13 byte block:
a3 1 5a 23 1 8 20 24 8 20 26 31 1c
(DW_OP_entry_value: (DW_OP_reg10 (a0));
DW_OP_plus_uconst: 1; DW_OP_const1u: 32;
DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra;
DW_OP_lit1; DW_OP_minus)
...
which has an upper bound using a DW_OP_entry_value, and since the
corresponding call site contains no information to resolve the value of a0 at
function entry:
...
<2><6b>: Abbrev Number: 6 (DW_TAG_call_site)
<6c> DW_AT_call_return_pc: 0x638
<74> DW_AT_call_origin : <0x85>
...
evaluting the dwarf expression fails, and we get <optimized out>.
My first thought was to try breaking at *f1 instead of f1 to see if that would
help, but actually the breakpoint resolved to the same address.
In other words, the inferior is stopped at function entry.
Fix this by resolving DW_OP_entry_value when stopped at function entry by
simply evaluating the expression.
This handles these two cases (x86_64, using reg rdi):
- DW_OP_entry_value: (DW_OP_regx: 5 (rdi))
- DW_OP_entry_value: (DW_OP_bregx: 5 (rdi) 0; DW_OP_deref_size: 4)
Tested on x86_64-linux.
Tested gdb.base/vla-optimized-out.exp on riscv64-linux.
Tested an earlier version of gdb.dwarf2/dw2-entry-value-2.exp on
riscv64-linux, but atm I'm running into trouble on that machine (cfarm92) so
I haven't tested the current version there.
Tom de Vries [Wed, 9 Apr 2025 06:59:42 +0000 (08:59 +0200)]
[gdb/tdep] Handle ldaex and stlex in {thumb,arm}_deal_with_atomic_sequence_raw
The Linaro CI reported a regression [1] in test-case
gdb.base/step-over-syscall.exp due to commit 674d4856730 ("[gdb/testsuite] Fix
gdb.base/step-over-syscall.exp with glibc 2.41").
Investigation shows that it's a progression in the sense that the test-case
fails at a later point than before.
The cause for the test-case failure is that an atomic sequence
ldaex/adds/strex is not skipped over when instruction stepping, leading to a
hang (in the sense of not being able to instruction-step out of the loop
containing the atomic sequence).
The arm target does have support for recognizing atomic sequences, but it
fails because it doesn't recognize the ldaex insn.
Fix this by:
- adding a new function ldaex_p which recognizes ldaex instructions, based
on information found in opcodes/arm-dis.c, and
- using ldaex_p in thumb_deal_with_atomic_sequence_raw.
I was not able to reproduce the failure in its original setting, but I
was able to do so using a test.c:
...
static void exit (int status) {
while (1)
;
}
void _start (void) {
int a = 0;
__atomic_fetch_add (&a, 1, __ATOMIC_ACQUIRE);
exit (0);
}
...
compiled like this:
...
$ gcc test.c -march=armv8-a -mfloat-abi=soft -nostdlib -static
...
giving this atomic sequence of 32-bit Thumb-2 instructions:
...
100ce: e8d3 1fef ldaex r1, [r3]
100d2: f101 0101 add.w r1, r1, #1
100d6: e843 1200 strex r2, r1, [r3]
...
Without the fix, after 100 stepi's we're still in _start (and likewise with
10.000 stepi's):
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
...
0x000100dc in _start ()
1: x/i $pc
=> 0x100dc <_start+26>: bne.n 0x100ce <_start+12>
...
but with the fix we've managed to progress to exit:
...
$ gdb -q -batch a.out -ex 'display /i $pc' -ex starti -ex "stepi 100"
...
0x000100c0 in exit ()
1: x/i $pc
=> 0x100c0 <exit+8>: b.n 0x100c0 <exit+8>
...
Having addressed the "-mthumb" case, do we need a similar fix for "-marm"?
Adding "-marm" in the compilation line mentioned above gives the following
atomic sequence:
...
100e4: e1931e9f ldaex r1, [r3]
100e8: e2811001 add r1, r1, #1
100ec: e1832f91 strex r2, r1, [r3]
...
and gdb already recognizes it as such because of this statement:
...
if ((insn & 0xff9000f0) != 0xe1900090)
return {};
...
The trouble with this statement is that it requires knowledge of arm
instruction encoding to understand which cases it does and doesn't cover.
Note that the corresponding comment only mentions ldrex:
...
/* Assume all atomic sequences start with a ldrex{,b,h,d} instruction. ... */
...
but evidently at least some forms of ldaex are also detected.
So, also use ldaex_p in arm_deal_with_atomic_sequence_raw. This may or may
not be redundant, but at least ldaex_p is explicit and precise about what it
supports.
Likewise for stlex (generated when using __ATOMIC_RELEASE instead of
__ATOMIC_ACQUIRE in the example above).
Tom Tromey [Sun, 6 Apr 2025 18:58:55 +0000 (12:58 -0600)]
Simplify print_doc_line
print_doc_line uses a static buffer and manually manages memory. I
think neither of these is really needed, so this patch rewrites the
function to use std::string. The new implementation tries to avoid
copying when possible.
Simon Marchi [Mon, 7 Apr 2025 17:52:01 +0000 (13:52 -0400)]
gdb/dwarf2: pass correct dwarf2_cu to lookup_dwo_id in create_cus_hash_table
Commit 71a48752660b ("gdb/dwarf: remove create_dwo_cu_reader")
introduced a regression when handling files compiled with "-gsplit-dwarf
-fdebug-types-section" (at least with clang):
The problem introduced by the aforementioned commit is that when
creating a dwo_unit structure representing the type unit, we use the
signature (DWO id) from the skeleton, instead of the signature from the
type unit's header. As a result, all dwo_units get created with the
same signature (the DWO id) and only the first unit gets inserted in the
hash table. When looking up the comp unit by DWO ID later on, we
wrongly find the type unit, and try to expand a type unit as a comp
unit, hitting the assert.
Before that commit, we passed `reader.cu ()` to lookup_dwo_id, which
yields a dwarf2_cu built from parsing the type unit's header. This
dwarf2_cu contains the comp_unit_header with the correct signature. Fix
the code to use `reader.cu ()` again.
Another thing that enables this bug is the fact that since DWARF 5, type
and compile units are all in .debug_info, and therefore read by
create_cus_hash_table, so they both end up in dwo_file::cus. Type units
should end up in dwo_file::tus, otherwise they won't be found by
lookup_dwo_cutu. This bug hasn't given me trouble so far, so I'm not
fixing it right now, but it's on my todo list.
The problem can be seen with some tests, when using the
dwarf5-fission-debug-types board:
$ make check TESTS="gdb.cp/expand-sals.exp" RUNTESTFLAGS="--target_board=dwarf5-fission-debug-types CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.cp/expand-sals.exp ...
FAIL: gdb.cp/expand-sals.exp: gdb_breakpoint: set breakpoint at main (GDB internal error)
But this patch also adds a DWARF assembler-based test that triggers the
internal error.
Note that the new test does not use the build_executable_and_dwo_files
proc, because I found that it is subtly broken and doesn't work to put
multiple units in a single .dwo file. The debug abbrev offset field in
the second unit's header would be 0, when it should have been something
else. The problem is that no linking is ever done to generate the .dwo
file, so the relocation that would apply for this field is never
applied. Instead, I generate two DWARF debug infos separately and link
the .dwo file using gdb_compile, it seems to work fine.
Change-Id: I96f809c56f703e25f72b8622c32e6bb91de20d6a Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 7 Apr 2025 17:52:00 +0000 (13:52 -0400)]
gdb/testsuite/dwarf: fix abbrev section name when putting type unit in DWO file
Fix what looks like a copy paste error resulting in the wrong abbrev
section name. The resulting section name in my test was
".debug_info.dwo.dwo", when it should have been ".debug_abbrev.dwo".
Change-Id: I82166d8ac6eaf3c3abc15d2d2949d00c31fe79f4 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 7 Apr 2025 17:51:59 +0000 (13:51 -0400)]
gdb/testsuite/dwarf: add support to generate DWARF 5 split compile units
Add support to the DWARF assembler to generate DWARF 5 split compile
units. The assembler knows how to generate DWARF < 5 split compile
units (fission), DWARF 5 compile units, but not DWARF 5 split compile
units. What's missing is:
- using the right unit type in the header: skeleton for the unit in the
main file and split_compile for the unit in the DWO file
- have a way for the caller to specify the DWO ID that will end up in
the unit header
Add a dwo_id parameter to the cu proc. In addition to specifying the
DWO ID, the presence of this parameter tells the assembler to use the
skeleton or split_compile unit type.
This is used in a subsequent patch.
Change-Id: I05d9b189a0843ea6c2771b1d5e5a91762426dea9 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 7 Apr 2025 17:51:58 +0000 (13:51 -0400)]
gdb/testsuite: add DWARF 5 + split DWARF + type units board
I'm currently fixing bugs and performance issues when GDB encounters
this particular configuration. Since split DWARF + type units makes GDB
take some code paths not taken by any other board files, I think it
deserves to be its own board file. One particularity is that the
produced .dwo files have a .debug_info.dwo section that contains some
ype units, in addition to the compile unit.
Add that board to make-check-all.sh.
Change-Id: I245e6f600055a27e0c31f1a4a9af1f68292fe18c Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 2 Apr 2025 19:30:10 +0000 (13:30 -0600)]
Update copyright dates to include 2025
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Lulu Cai [Wed, 2 Apr 2025 02:23:40 +0000 (10:23 +0800)]
LoongArch: Warn about right shifts of negative numbers
The GNU Assembler User Guide says that the right shift operator ">>"
in an expression is the same as the C operator.
On LoongArch the assembler directives and instructions do not treat
negative numbers ">>" the same way. The directives treats negative
numbers ">>" as logical right shifts while the instructions treats them
as arithmetic right shifts.
The right shift of negative numbers in the instructions may be changed
from an arithmetic right shift to a logical right shift in the future,
and a warning is issued for this.
Tom de Vries [Mon, 7 Apr 2025 20:40:04 +0000 (22:40 +0200)]
[gdb/cli] Use debug info language to pick pygments lexer
Consider the following scenario:
...
$ cat hello
int
main (void)
{
printf ("hello\n");
return 0;
}
$ gcc -x c hello -g
$ gdb -q -iex "maint set gnu-source-highlight enabled off" a.out
Reading symbols from a.out...
(gdb) start
Temporary breakpoint 1 at 0x4005db: file hello, line 6.
Starting program: /data/vries/gdb/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Temporary breakpoint 1, main () at hello:6
6 printf ("hello\n");
...
This doesn't produce highlighting for line 6, because:
- pygments is used for highlighting instead of source-highlight, and
- pygments guesses the language for highlighting only based on the filename,
which in this case doesn't give a clue.
Fix this by:
- adding a language parameter to the extension_language_ops.colorize interface,
- passing the language as found in the debug info, and
- using it in gdb.styling.colorize to pick the pygments lexer.
The new test-case gdb.python/py-source-styling-2.exp excercises a slightly
different scenario: it compiles a c++ file with a .c extension, and checks
that c++ highlighting is done instead of c highlighting.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR cli/30966
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966
I noticed that if deferred curses initialization fails, for instance when
using TERM=dumb, and we try the same again, we run into the same error:
...
$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
...
I think it's better to try deferred curses initialization only once.
Fix this by changing bool tui_finish_init into a tribool, and using
TRIBOOL_UNKNOWN to represent the "initialization failed" state, such that we
get instead:
...
$ TERM=dumb gdb -batch -ex "tui enable" -ex "tui enable"
Cannot enable the TUI: terminal doesn't support cursor addressing [TERM=dumb]
Cannot enable the TUI
...
Michael Matz [Mon, 31 Mar 2025 13:57:08 +0000 (15:57 +0200)]
[lto] Fix symlookup in archives vs shared
when a shared library defines 'foo@@FOO' (default version),
a static archive defines 'foo', the shared lib comes in front
of the archive and under effect of --as-needed, and the requesting
object file uses LTO, then the link editor was wrongly including
the definition from the static archive. It must use the one
from the shared lib, like in the non-LTO or the --no-as-needed case.
See the added testcase that would wrongly print "FAIL" before
this patch.
The problem stems from several connected problems:
(1) only the decorated symbol was entered into first_hash (the hash
table designed to handle definition order in the pre-LTO-plugin
phase of the symbol table walks)
(2) in the archive symbol walk only the undecorated name would be
looked up in first_hash (and hence not found due to (1))
(3) in the archive symbol walk first_hash would only be consulted
when the linker hash table had a defined symbol. In pre-LTO
phase shared lib symbols aren't entered into the linker symbol
table.
So: add also the undecorated name into first_hash when it stems from
a default version and consult first_hash in the archive walker also
for currently undefined symbols. If it has an entry which doesn't
point to the archive, then it comes from an earlier library (shared or
static), and so _this_ archive won't provide the definition.
Alan Modra [Mon, 7 Apr 2025 00:37:51 +0000 (10:07 +0930)]
xcoff dynamic symbol string sanity
Sanity check symbol string table offsets, and tidy structs. "long"
isn't a good choice for _l_zeroes and _l_offset since it can be 64
bits which blows out the size of the symbol struct unnecessarily.
Also, all of the sizes in internal_ldsym need only be 32 bits, but I
made them size_t because I didn't want to audit all expressions using
them for overflow.
bfd/
* xcofflink.c (_bfd_xcoff_canonicalize_dynamic_symtab): Sanity
check symbol _l_offset.
(xcoff_link_add_dynamic_symbols),
(xcoff_link_check_dynamic_ar_symbols): Likewise.
include/
* coff/xcoff.h (struct internal_ldhdr): Tidy types.
(struct internal_ldsym): Use uint32_t for _l_zeroes and _l_offset.
Guinevere Larsen [Thu, 13 Mar 2025 13:20:53 +0000 (10:20 -0300)]
gdb: Introduce user-friendly namespace identifier for "info shared"
GDB has had basic support for linkage namespaces for some time already,
but only in the sense of managing multiple copies of the same shared
object being loaded, and a very fragile way to find the correct copy of
a symbol (see PR shlibs/32054).
This commit is the first step in improving the user experience around
multiple namespace support. It introduces a user-friendly identifier for
namespaces, in the format [[<number>]], that will keep consistent between
dlmopen and dlclose calls. The plan is for this identifier to be usable
in expressions like `print [[1]]::var` to find a specific instance of a
symbol, and so the identifier must not be a valid C++ or Ada namespace
identifier, otherwise disambiguation becomes a problem. Support for
those expressions has not been implemented yet, it is only mentioned to
explain why the identifier looks like this.
This syntax was chosen based on the C attributes, since nothing in GDB
uses a similar syntax that could confuse users. Other syntax options
that were explored were "#<number>" and "@<number>". The former was
abandoned because when printing a frame, the frame number is also
printed with #<number>, so in a lot of the context in which that the
identifier would show up, it appears in a confusing way. The latter
clashes with the array printing syntax, and I believe that the having
"@N::foo" working completely differently to "foo@2" would also lead to a
bad user experience.
The namespace identifiers are stored via a vector inside svr4_info
object. The vector stores the address of the r_debug objects used by
glibc to identify each namespace, and the user-friendly ID is the index
of the r_debug in the vector. This commit also introduces a set storing
the indices of active namespaces. The glibc I used to develop this patch
(glibc 2.40 on Fedora 41) doesn't allow an SO to be loaded into a
deactivated namespace, and requesting a new namespace when a namespace
was previously closed will reuse that namespace. Because of how this is
implemented, this patch lets GDB easily track the exact namespace IDs
that the inferior will see.
Finally, two new solib_ops function pointers were added, find_solib_ns
and num_active_namespaces, to allow code outside of solib-svr4 to find
and use the namespace identifiers and the number of namespaces,
respectively. As a sanity check, the command `info sharedlibrary` has
been changed to display the namespace identifier when the inferior has
more than one active namespace. With this final change, a couple of tests
had to be tweaked to handle the possible new column, and a new test has
been created to make sure that the column appears and disappears as
needed, and that GDB can track the value of the LMID for namespaces.
Jeremy Drake [Mon, 7 Apr 2025 11:19:28 +0000 (13:19 +0200)]
bfd: add load config size workaround for i386 XP and earlier
Per the Microsoft PE documentation, XP and earlier on i686 require the
Size field to be 64, rather than the actual size as required on other
architectures. I have confirmed Windows 11 accepts either 64 or the
actual size for i386 images, but only the actual size for x86_64 images.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
Jeremy Drake [Mon, 7 Apr 2025 11:19:10 +0000 (13:19 +0200)]
bfd: adjust a few error messages
Rationalize the error messages in _bfd_XXi_final_link_postscript().
They now all correctly refer to DataDirectory instead of DataDictionary,
and use unified format strings, so fewer translations are needed.
Signed-off-by: Jeremy Drake <sourceware-bugzilla@jdrake.com>
Jan Beulich [Mon, 7 Apr 2025 10:46:16 +0000 (12:46 +0200)]
bfd/COFF: drop link_add_one_symbol() hook
The need for this has disappeared with dc12032bca08 ("Remove m68k-aout
and m68k-coff support"); avoid the unnecessary indirection.
Sadly, with ld/pe-dll.c using the wrapper, the removal requires moving
the declaration out of libcoff.h, to properly export the underlying BFD
function.
Jan Beulich [Mon, 7 Apr 2025 10:45:30 +0000 (12:45 +0200)]
nm: fall back to heuristic when ELF symbol has zero size
Size being set for a symbol isn't a strict requirement in ELF. For ones
not having their size set, fall back to the same logic as used for non-
ELF, non-COFF symbols.
While there switch to using elf_symbol_from() instead of kind of open-
coding it.
Jan Beulich [Mon, 7 Apr 2025 10:45:11 +0000 (12:45 +0200)]
nm: also retrieve size for COFF function symbols
Like ELF for all symbols, COFF can record size for at least function
ones. Use that - if available - in preference to the distance-to-next-
symbol heuristic.
To be able to use the new test there, make TI C54x follow TI C4x in
providing .sdef to cover for .def already having different meaning.
Remove all duplicate symbols which can be in SymLst. The duplication
is due to processing of both static and dynamic symbols. The
Stabs::removeDupSyms function is called before computing symbol
aliases.
Introduce a new vector function (i.e., truncate()), that truncates a
vector lenght to the given new count. This functionis used by
removeDupSyms function.
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>
projects / thirdparty / binutils-gdb.git / log
