Some of these files we want to skip in a spell check, because they're
generated. We also want to skip ChangeLogs, we don't actively maintain those.
Add a file gdbsupport/setup.cfg with a codespell section, that skips those
files. The choice for setup.cfg (rather than say .codespellrc) comes from the
presence of gdb/setup.cfg.
That leaves invokable, configury and useable. I think configury is a common
expression in our context, and for invokable and useable I don't manage to
find out whether they really need rewriting, so I'd rather leave them alone
for now.
Add these to a file gdb/contrib/codespell-ignore-words.txt, and use the file in
gdbsupport/setup.cfg.
This makes the directory codespell clean:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport
$
...
Because codespell seems to interpret filenames relative to the working
directory rather than relative to the config file, and the filename used in
gdbsupport/setup.cfg is gdb/contrib/codespell-ignore-words.txt, this simple
invocation doesn't work:
...
$ cd gdbsupport
$ codespell
...
because codespell can't find gdbsupport/gdb/contrib/codespell-ignore-words.txt.
We could fix this by using ../gdb/contrib/codespell-ignore-words.txt instead, but
likewise that breaks this invocation:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport
...
I can't decide which one is worse, so I'm sticking with
gdb/contrib/codespell-ignore-words.txt for now.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Wed, 5 Mar 2025 19:13:40 +0000 (14:13 -0500)]
gdb: remove unnecessary local variable in pager_file::puts
The lineptr variable isn't really necessary, we can just keep using
linebuffer, since the original value is linebuffer isn't needed. Remove
lineptr, and fix some comparisons to be explicit.
Change-Id: If2f7df43bf79efd40149e46d5c77f9bc0439f879 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Mon, 27 Jan 2025 23:58:12 +0000 (16:58 -0700)]
Use "::" as separator for Fortran in cooked index
This teaches cooked_index_entry::full_name that "::" is the separator
for Fortran. I don't know enough Fortran to write a test case for
this. However, a different series I am working on has a regression if
this patch is not applied.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Mon, 24 Feb 2025 20:18:27 +0000 (13:18 -0700)]
Avoid double-decoding in ada_add_global_exceptions
I noticed that ada_add_global_exceptions calls ada_decode on
'search_name' -- and then passes this to name_matches_regex, which
also calls ada_decode.
name_matches_regex is also used later, where the result of
'natural_name ()' is passed to it -- but natural_name also calls
ada_decode.
So, I think the call to ada_decode in name_matches_regex is redundant.
This patch removes it, and turns name_matches_regex into an inner
function to avoid propagating its use.
Note that, right now, the DWARF implementation of
expand_symtabs_matching does not in fact pass an encoded name to this
callback. So, this code remains slightly (but currently harmlessly)
wrong. expand_symtabs_matching is fixed by another pending series of
mine.
H.J. Lu [Wed, 5 Mar 2025 11:08:49 +0000 (19:08 +0800)]
ld: Update PR ld/25237 test
1. Skip targets which don't support the .bss section alignment, 1 << 16.
2. Replace .bss with ".section .bss".
3. Use ".zero 0xb60000" for targets which pad the section to its alignment.
PR ld/25237
* testsuite/ld-elf/pr25237.d: Skip avr-*-* and h8300-*-*.
Update expected segment size to 0xb60000.
* testsuite/ld-elf/pr25237.s: Use ".section .bss" and
".zero 0xb60000".
Guinevere Larsen [Fri, 21 Feb 2025 13:06:03 +0000 (10:06 -0300)]
gdb/testsuite: add test for memory requirements of gcore
For a long time, Fedora has been carrying an out-of-tree patch with a
similar test to the one proposed in this patch, that ensures that the
memory requirements don't grow with the inferior's memory. It's been
so long that the context for why this test exists has been lost, but
it looked like it could be interesting for upstream.
The test runs twice, once with the inferior allocating 4Mb of memory,
and the other allocating 64Mb. My plan was to find the rate at which
things increase based on inferior size, and have that tested to ensure
we're not growing that requirement accidentally, but my testing
actually showed memory requirements going down as the inferior increases,
so instead I just hardcoded that we need less than 2Mb for the command,
and it can be tweaked later if necessary.
Simon Marchi [Wed, 5 Mar 2025 16:28:15 +0000 (11:28 -0500)]
gdb: do not handle a NULL linebuffer in pager_file::puts
This patch [1] has shown that different implementations of ui_file::puts
handle a NULL line differently. pager_file::puts handles a NULL
argument gracefully, as a no-op, while other implementations don't and
likely crash. This causes subtle bugs: things will be working until the
current ui_file is suddenly not a pager_file anymore. I think it would
be better to be consistent here, so change pager_file::puts to not
accept a NULL line.
Tom Tromey [Wed, 1 Jan 2025 21:34:10 +0000 (14:34 -0700)]
Inconsistent treatment of template parameters in DWARF reader
I noticed that if you hack some clean_restart calls into
paramless.exp, the test will fail. That is, the test currently relies
on the desired CUs already being expanded when trying to set a
breakpoint -- which is clearly a bug, the CU expansion state should
not affect "break".
I tracked this down to incorrect construction of a lookup_name_info in
cooked_index_functions::expand_symtabs_matching.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32510 Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Wed, 5 Mar 2025 05:06:43 +0000 (00:06 -0500)]
gdb/dwarf: store dwo_file_up in dwo_file_set
Heap-allocated dwo_file objects, stored in dwarf2_per_bfd::dwo_files,
are never freed. They are created in one of the
create_dwo_unit_in_dwp_* or lookup_dwo_cutu functions. I confirmed this
by running:
... and checking the ASan leak report. I also debugged this invocation
of GDB, placed a breakpoint on ~dwo_file, and didn't see any hit.
Change the dwo_file set to hold dwo_file_up objects. When the
dwarf2_per_bfd object gets destroyed, dwo_file objects will
automatically get destroyed. With this change, I see the related leaks
disappear in the ASan leak report, and my ~dwo_file breakpoint gets hit
when debugging GDB.
Change-Id: Icb38539c3f9e553f3625c625a00fc63dd6e9f3c5 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 5 Mar 2025 05:06:42 +0000 (00:06 -0500)]
gdb/dwarf: make dwarf2_per_bfd::dwo_files a gdb::unordered_set
Change the dwarf2_per_bfd::dwo_files htab to a gdb::unordered_set.
No behavior change expected, except maybe the failure case in
lookup_dwo_cutu. If open_and_init_dwo_file returns nullptr, the
previous code would leave the slot value empty (nullptr). Is this
legit? With the new hash table, the only thing we can do really is not
attempt to insert the nullptr value.
Change-Id: I63992f388b1197e696ded4ea483634e8ae67fce4 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 5 Mar 2025 05:06:41 +0000 (00:06 -0500)]
gdb/dwarf: change htabs holding dwo_unit objects to gdb::unordered_set
Change a few occurences of htabs holding `dwo_unit *` values, using
their signature as identity, to gdb::unordered_set.
allocate_dwo_unit_table and allocate_dwp_loaded_cutus_table appeared to
create hash tables with identical behavior, so they both use the same
set type now.
The only expected change in behavior is that when there are multiple
units with the same signature, we will now keep the unit previously in
the set, rather than overwriting it. But this seems ok, as it's a case
of bad DWARF.
Also, in the complaint in create_debug_type_hash_table, I think we
previously erroneously printed the same sect_off twice.
Change-Id: I57739977735ee1fd5c7b754107f5624f0621baa5 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 5 Mar 2025 05:06:38 +0000 (00:06 -0500)]
gdb/dwarf: remove die_reader_specs
die_reader_specs is a relic of some past design, today it only serves as
(useless) a base class for cutu_reader. Remove it and move all its
fields to cutu_reader.
Change-Id: I5d55018eb8c6e0b828ef5d2f6d09b2047d1a5912 Approved-By: Tom Tromey <tom@tromey.com>
Daniel Starke [Tue, 4 Mar 2025 21:50:11 +0000 (22:50 +0100)]
gdb: fix null pointer dereference on missing PATH variable
When running "show" with missing PATH variable a null pointer is being
dereferenced in path_info().
path_command() correctly checks whether PATH has been set before using it.
It then calls path_info() which retrieves the variable again but fails to
perform the null pointer test on it. As a result, the application crashes with
SIGSEGV on Windows for example.
Fix this by handling the null pointer case in path_info() accordingly.
Signed-off-by: Daniel Starke <daniel-email@gmx.net> Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I41ef10f00802d3163793491454190008e78f5dc1
Tom Tromey [Fri, 28 Feb 2025 03:26:13 +0000 (20:26 -0700)]
Dump debug names index
This changes the .debug_names reader to dump the contents of the
index. This follows what the cooked index does, and also fixes a
couple of test failures when run with the debug-names board:
forward-spec-inter-cu.exp and backward-spec-inter-cu.exp.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
H.J. Lu [Wed, 5 Mar 2025 04:44:11 +0000 (12:44 +0800)]
ld: Pass -Wl,-z,lazy to compiler for i386 lazy binding tests
Pass -Wl,-z,lazy to compiler for i386 tests which require lazy binding
to support compilers which default to non-lazy binding.
PR ld/32762
* testsuite/ld-i386/i386.exp: Pass -Wl,-z,lazy for
"Build ifunc-1a with PIE -z ibtplt" test.
* testsuite/ld-i386/no-plt.exp: Pass -Wl,-z,lazy for
"Build libno-plt-1b.so", "No PLT (dynamic 1a)",
"No PLT (dynamic 1b)", "No PLT (dynamic 1c)",
"No PLT (PIE 1e)", "No PLT (PIE 1f)", "No PLT (PIE 1g)" tests.
Simon Marchi [Mon, 3 Mar 2025 21:35:37 +0000 (16:35 -0500)]
gdb/dwarf: pass is_dwz to dwarf2_per_cu constructor
It is always known at construction time whether a dwarf2_per_cu is
built to represent a unit from a dwz file or not, so pass that
information through the constructor.
Change-Id: I278c1894ed606451aad02e830085190bb724c473 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 3 Mar 2025 21:35:35 +0000 (16:35 -0500)]
gdb/dwarf: remove create_cu_from_index_list
I noticed that create_cu_from_index_list is only used in
read-gdb-index.c, so I started by moving it there. But given that this
function is use at only one spot and doesn't do much, I opted to inline
its code in the caller instead.
Change-Id: Iebe0dc20d345fa70a2f11aa9ff1a04fe26a31407 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 12 Feb 2025 17:56:43 +0000 (10:56 -0700)]
Look for -fgnat-encodings option
gnat-llvm does not support the -fgnat-encodings option, and does not
emit GNAT encodings at all -- it only supports the equivalent of GCC's
"minimal" encodings; which is to say, ordinary DWARF.
This patch changes gdb to test whether gnatmake supports this flag and
adapt accordingly. foreach_gnat_encoding is changed to pretend that
the "minimal" mode is in effect, as some test examine the mode.
Tom Tromey [Wed, 12 Feb 2025 17:51:33 +0000 (10:51 -0700)]
Check -fvar-tracking via ada_simple_compile
A couple of Ada tests check whether the C compiler supports
-fvar-tracking. However, this doesn't really work when using
gnat-llvm, because that will invoke clang under the hood. This patch
arranges to check gnatmake instead, which is more robust even when
toolchains are mix-and-matched.
Tom Tromey [Wed, 12 Feb 2025 17:28:14 +0000 (10:28 -0700)]
Introduce ada_simple_compile
This introduces ada_simple_compile, an Ada-specific analog of
gdb_simple_compile. gdb_compile_test is split into two procs to make
this possible. ada_simple_compile isn't used in this patch but will
be by later patches in this series.
Tom Tromey [Wed, 12 Feb 2025 16:35:26 +0000 (09:35 -0700)]
Check for compiler support in scalar_storage.exp
gnat-llvm does not currently handle Scalar_Storage_Order. This patch
changes the scalar_storage.exp test to check the compiler error
messages and report "unsupported" in this case. This way, the test
ought to start working automatically if this feature is added to
gnat-llvm.
Matthieu Longo [Tue, 25 Feb 2025 11:29:01 +0000 (11:29 +0000)]
refactoring elf_find_and_remove_property
This refactoring focuses primarily on code readability and reuse.
- Use the already defined _bfd_elf_find_property instead of another
raw for-loop.
- Extract _bfd_elf_remove_property out of the function body.
Matthieu Longo [Mon, 24 Feb 2025 18:32:08 +0000 (18:32 +0000)]
refactoring _bfd_elf_get_property
- Extract _bfd_elf_find_property and _bfd_elf_insert_property from the
function's body to improve the code readability.
- Export _bfd_elf_find_property's symbol as it will be used in a later
commit.
- remove the definition of the search predicate outside of the for loop.
- change the function's return type to struct to adopt a more functional
coding style.
Matthieu Longo [Thu, 20 Feb 2025 16:14:03 +0000 (16:14 +0000)]
aarch64: setup_gnu_properties only creates the notes section when none exists
The creation of .note.gnu.property section should not be based on the
presence of GNU properties, but rather on whether this section exits
or not.
However, there is one exception to this: PR23900 [1]. Old linkers were
treating .note.gnu.property as a generic note section, so old objects
might contain properties inside .note instead of .note.gnu.property. In
this case, the section won't be detected but the properties are still
parsed. So the absence of the .note.gnu.property section is necessary
but not enough to create the section. The condition of the creation of
the section has also to include the absence of GNU properties.
Matthieu Longo [Tue, 21 Jan 2025 13:49:27 +0000 (13:49 +0000)]
clean-up: move writing of build attributes section into a function
- add obj_build_attributes to struct elf_backend_data similarly sframe.
- new function _bfd_elf_write_section_build_attributes encapsulating the
writing of the build attributes section into a function.
Matthieu Longo [Fri, 24 Jan 2025 15:19:36 +0000 (15:19 +0000)]
clean-up readelf: simplify and flatten body of process_attributes
- use find_section_by_type() instead of a for-loop.
- reindent the whole function accordingly.
- move declaration of variables nearer from their usage.
- prune else branch by using a goto in the error case.
diff --git a/binutils/readelf.c b/binutils/readelf.c
index 6d3ec65a8a1..878012da8f0 100644
--- a/binutils/readelf.c
+++ b/binutils/readelf.c
@@ -19268,42 +19268,32 @@ process_attributes (Filedata * filedata,
unsigned char * (* display_pub_attribute) (unsigned char *, const unsigned char * const),
unsigned char * (* display_proc_gnu_attribute) (unsigned char *, unsigned int, const unsigned char * const))
{
- Elf_Internal_Shdr * sect;
- unsigned i;
- bool res = true;
-
/* Find the section header so that we get the size. */
- for (i = 0, sect = filedata->section_headers;
- i < filedata->file_header.e_shnum;
- i++, sect++)
- {
- unsigned char * contents;
- unsigned char * p;
+ Elf_Internal_Shdr * sect = find_section_by_type (filedata, proc_type);
+ if (sect == NULL)
+ sect = find_section_by_type (filedata, SHT_GNU_ATTRIBUTES);
- if (sect->sh_type != proc_type && sect->sh_type != SHT_GNU_ATTRIBUTES)
- continue;
+ if (sect == NULL)
+ /* No section, exit without error. */
+ return true;
- p = contents;
+ bool res = true;
+ unsigned char * p = contents;
/* The first character is the version of the attributes.
Currently only version 1, (aka 'A') is recognised here. */
if (*p != 'A')
{
printf (_("Unknown attributes version '%c'(%d) - expecting 'A'\n"), *p, *p);
res = false;
+ goto free_data;
}
- else
- {
- uint64_t section_len;
Tom Tromey [Fri, 14 Feb 2025 00:47:23 +0000 (17:47 -0700)]
Display entry offset for .debug_names
Since commit ad6dde5aaae ("gdb/dwarf: write offset to parent entry for
DW_IDX_parent"), gdb now emits a .debug_names where the DW_IDX_parent
attribute refers to the parent entry's offset -- previously, due to
some confusion in the standard, gdb used the index of the parent's
name table entry.
This patch changes the .debug_names display code to display each
entry's offset. This makes it easy to refer from a DW_IDX_parent to
the correct entry.
Alan Modra [Fri, 28 Feb 2025 07:26:48 +0000 (17:56 +1030)]
objdump: is_same_section
This fixes a deficiency in commit 660df28acfa1, which should have used
the same logic as that in sym_ok. Ideally both places would not
compare section names, but it can be a little tricky to match a
section in the real object file with a section in a debug file.
Extend commit 39f0547e554d to use section name, vma and size.
* objcopy (is_same_section): New function.
(compare_symbols, sym_ok): Use it here.
Alan Modra [Thu, 27 Feb 2025 10:23:43 +0000 (20:53 +1030)]
rescoff: ensure file is PE
read_coff_rsrc makes one check on object file contents, the existence
of a .rsrc section. It doesn't check that the file is PE but blindly
accesses bfd pe_data. Fix that by adding the necessary checks.
Also, the "resources nest too deep" error isn't an overrun, ie. the
"address out of bounds" message isn't correct. Fix that too.
Alan Modra [Mon, 24 Feb 2025 06:27:53 +0000 (16:57 +1030)]
Move BFD_FAKE_SECTION to libbfd.h
BFD_FAKE_SECTION and its sidekick GLOBAL_SYM_INIT don't need to be
cluttering bfd.h, and probably shouldn't be used outside bfd/. To
make them internal to bfd, make the bfd ecoff small common section
declaration global so it can be used instead of a duplicate in
gas/ecoff.c. Oddly this needs to go in bfd/ecofflink.c rather than
bfd/ecoff.c as the former is compiled for all targets needing the
ecoff small common section (some via a call in gas/config/obj-elf.c to
a function in gas/ecoff.c) while the latter is not.
While doing this rename ecoff_scom_section to _bfd_ecoff_scom_section
and remove support for traditional C from GLOBAL_SYM_INIT.
Tom Tromey [Sun, 19 Jan 2025 22:42:51 +0000 (15:42 -0700)]
Add language to type unit in debug-names-tu.exp.tcl
I think debug-names-tu.exp.tcl only passes by accident -- the type
unit does not have a language, which gdb essentially requires.
This isn't noticeable right now because the type unit in question is
expanded in one phase and then the symbol found in another. However,
I'm working on a series that would regress this.
This patch partially fixes the problem by correcting the test case,
adding the language to the TU.
Hoewver, it then goes a bit further and arranges for this information
not to be written to .debug_names. Whether or not a type should be
considered "static" seems like something that is purely internal to
gdb, so this patch has the entry-creation function apply the
appropriate transform.
It also may make sense to change the "debug_names" proc in the test
suite to process attributes more like the ordinary "cu" proc does.
This scratches an itch I had for a while. I don't know why this struct
type has "data" in its name. Others like "dwarf2_per_objfile" and
"dwarf2_per_bfd" don't. The primary job of a structure is to hold data,
there's no need to specify it. It also makes the name a bit shorter,
which is always nice.
Rename related types too.
Change-Id: Ifb63195ff105809fc15b502f639c0bb4d18a675e Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Simon Farre [Mon, 3 Mar 2025 17:53:12 +0000 (18:53 +0100)]
Bploc should try to return full path
Compilers often emit relative paths in the line number program,
relative to the build directory for that compilation unit (if it's
DWARF>=4 I think).
Therefore use symtab->fullname() when not null as this seemingly
has attempted path normalization for the symtab and only
fall back on symtab->filename which will never be null if that fails.
This has a much better UX. Applications may choose to expose
this name as a clickable link to some file, at which point
a non-normalized and non-absolute path would lead nowhere.
When I wrote this feature the first time, I don't think this
relative-to-cu-scheme was as prevalent in the output of gcc/clang
for DWARF.
Tom de Vries [Mon, 3 Mar 2025 16:13:21 +0000 (17:13 +0100)]
[gdb/doc] Indicate in which languages 'filename'::funcaddr works
In the docs I read [1]:
...
In this section, we discuss operators that you can use in GDB expressions
regardless of your programming language.
...
GDB supports these operators, in addition to those common to programming
languages:
‘::’ allows you to specify a variable in terms of the file or function
where it is defined. See Program Variables.
...
In fact, this is not supported in Ada:
...
(gdb) b *'foo.adb'::foo
No file or function "foo.adb'".
(gdb)
...
and likewise in a few other working languages.
Fix this by making this restriction explicit.
Approved-By: Eli Zaretskii <eliz@gnu.org>
PR gdb/32753
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32753
Tom de Vries [Mon, 3 Mar 2025 16:13:20 +0000 (17:13 +0100)]
[gdb/doc] Fix address location with file prefix
In the docs I read [1]:
...
Address locations indicate a specific program address. They have the
generalized form *address.
funcaddr
An address of a function or procedure derived from its name.
...
'filename':funcaddr
Like funcaddr above, but also specifies the name of the source file
explicitly. This is useful if the name of the function does not specify
the function unambiguously, e.g., if there are several functions with
identical names in different source files.
...
This is incorrect, the notation is in fact 'filename'::funcaddr.
Fix this by correcting the typo, and add a reference to "variable name
conflict", where the concept is explained in more detail.
Approved-By: Eli Zaretskii <eliz@gnu.org>
PR gdb/32748
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32748
Andrew Oates [Mon, 24 Feb 2025 07:36:54 +0000 (15:36 +0800)]
RISC-V: Re-define mapping symbol $x to the file elf architecture attribute
The mapping symbol "$x" without an ISA string "means using ISA
configuration from ELF attribute."[1]. Currently the code does not
reset the subset_list. This means that a previous mapping symbol that
overrides the ISA string will continue to be used, rather than the
default string set in the ELF file's .riscv.attributes section. This
can cause incorrect or failed instruction decodings.
In practice, this causes problems when disassembling code generated by
LLVM, which (unlike gas) does not emit explicit mapping symbols at the
start of each section.
This change stores the default architecture string seen at the beginning
of disassembly in the global parse data struct, and restores that to
subset_list whenever a bare "$x" symbol is seen.
Nelson Chu [Mon, 24 Feb 2025 07:36:53 +0000 (15:36 +0800)]
RISC-V: Stop generating mapping symbol $x, replace with $x<isa>.
The psABI defined $x to the architecture which is same as the file elf
attribute. But GNU defined it to that is same as the previous $x<isa>,
and always generated $x<isa> at the begining of each section. That is
because considering two objects have different architecture in their elf
attributes, then $x will always be wrong after linking since the merged
arch string will be changed. For example, object A with rv32ic and object
B with rv32ia, $x from A is rv32ic and $x from B is rv32ia, but the final
output is rv32ica, so $x from A and B need to be updated to rv32ic and
rv32ia by linker respectively. I think let linker to do this is not good,
so in order to follow the psABI, we will stop generating the $x for now.
Instead, all $x will be replaced with the corresponding $x<isa>. The
dis-assembler will also treat $x like what psABI defined.
Richard Allen [Sun, 16 Feb 2025 22:50:05 +0000 (16:50 -0600)]
gprof: only process line numbers for intersection of vmas and histograms
Some programs like RTOS firmware may have a large number of symbols.
By loading the histograms before loading symbols, we can look up
only the line numbers that were captured in the histogram file,
which reduces processing time for such a firmware from ~2 minutes
to ~2 seconds.
Richard Allen [Sun, 16 Feb 2025 22:50:01 +0000 (16:50 -0600)]
gprof: rename min_insn_size to insn_boundary
This distinction is important for architecures like Xtensa,
where 2B and 3B instructions are common, but the correct
value for instruction iteration is 1B, not 2B.
Nick Alcock [Mon, 24 Feb 2025 18:11:25 +0000 (18:11 +0000)]
libctf: fix cv-qualified unnamed struct/union field lookup
GCC permits not only unnamed structs and unions, but cv-qualified ones.
Our earlier fix in 6c3a38777b38a2ad87e2b2bcec4567578d1c83ec supported
unnamed structs and unions, but only unqualified ones.
Resolving away cvr-quals of nameless fields (and, irrelevantly, typedefs)
is easy and fixes this problem.
Tests adjusted accordingly.
libctf/
PR libctf/32746
* ctf-types.c (ctf_member_next): Resolve away cv-quals.
(ctf_member_info): Likewise.
* testsuite/libctf-lookup/struct-iteration-ctf.c: Add a cv-qualified
type or two: make sure to keep a non-qualified one.
* testsuite/libctf-lookup/struct-iteration.c: Verify consistency
of ctf_member_next and ctf_member_info.
* testsuite/libctf-lookup/struct-iteration.lk: Adjust.
Tested-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Nick Alcock [Tue, 11 Feb 2025 14:32:40 +0000 (14:32 +0000)]
libctf: fix slices of slices and of enums
Slices had a bunch of horrible usability problems. In particular, while
towers of cv-quals are resolved away by functions that need to do it, towers
of cv-quals with slices in the middle are not resolved away by functions
like ctf_enum_value that can see through slices: resolving volatile -> slice
-> const -> enum will leave it with a 'const', which will error pointlessly,
annoying callers, who reasonably expect slices to be more invisible than
this. (The user-callable ctf_type_resolve still does not resolve away
slices, because this is the only way users can see that the slices are there
at all.)
This is induced by a fix for another wart: ctf_add_enumerator does not
resolve anything away at all, so you can't even add enumerators to const or
volatile enums -- and more problematically, you can't add enumerators to
enums with an explicit encoding without resolving away the types by hand,
since ctf_add_enum_encoded works by returning a slice! ctf_add_enumerator
now resolves away all of those, so any cvr-or-typedef-or-slice-qual
terminating in an enum can be added to, exactly as callers likely expect.
(New tests added.)
libctf/
* ctf-create.c (ctf_add_enumerator): Resolve away cvr-qualness.
* ctf-types.c (ctf_type_resolve_unsliced): Don't terminate at
the first slice.
* testsuite/libctf-writable/slice-of-slice.*: New test.
<memory.h> is not needed and not standardized and is just an alias for
<string.h>.
<sys/param.h> is not needed and not standardized and contains a kitchen
sink of various unportable definitions not agreed upon and best done
manually or through other headers.
These fixes are needed to compile binutils on Sortix and other operating
systems with a strict POSIX.1-2024 libc without obsolete features.
Signed-off-by: Jonas 'Sortie' Termansen <sortie@maxsi.org>
Tom de Vries [Fri, 28 Feb 2025 13:13:02 +0000 (14:13 +0100)]
[gdb/testsuite] Fix gdb.base/nostdlib.exp on aarch64
On aarch64-linux, in test-case gdb.base/nostdlib.exp I run into:
...
(gdb) continue^M
Continuing.^M
warning: Temporarily disabling breakpoints for unloaded shared library \
"/lib/ld-linux-aarch64.so.1"^M
^M
Breakpoint 2, _start () at nostdlib.c:20^M
20 {^M
(gdb) FAIL: $exp: pie=pie: continue to marker
...
This happens as follows:
- the test-case sets a breakpoint on *_start,
- the breakpoint resolves to *_start in the executable,
- the executable is started, and the breakpoint resolves to *_start in the
dynamic linker,
- execution stops at *_start in the dynamic linker,
- the test-case issues a continue, expecting to continue to the breakpoint on
marker,
- while continuing, the dynamic linker is reported as unloaded,
- the breakpoint again resolves to *_start in the executable,
- execution stops at *_start in the executable, and
- the test-case concludes that it failed to "continue to marker".
This doesn't happen on x86_64-linux. There, after the executable is started,
the breakpoint again resolves to *_start in the exec.
This is similar to what happens when printing _start.
On aarch64-linux, we print the _start in the dynamic linker:
...
$ gdb -q -batch outputs/gdb.base/nostdlib/nostdlib-pie \
-ex "b _start" \
-ex run \
-ex "print _start" \
-ex "info break"
Breakpoint 1 at 0x2bc: file nostdlib.c, line 23.
Breakpoint 1.2, _start () at ../sysdeps/aarch64/dl-start.S:22
22 ENTRY (_start)
$1 = {void (void)} 0xfffff7fd6ac0 <_start>
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
breakpoint already hit 1 time
1.1 y 0x0000aaaaaaaa02bc in _start at nostdlib.c:23
1.2 y 0x0000fffff7fd6ac0 in _start at dl-start.S:22
...
On x86_64-linux, we print the _start in the exec:
...
Breakpoint 1 at 0x2c5: file nostdlib.c, line 23.
Breakpoint 1.2, 0x00007ffff7fe4f00 in _start () from \
/lib64/ld-linux-x86-64.so.2
$1 = {void (void)} 0x5555555542c1 <_start>
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
breakpoint already hit 1 time
1.1 y 0x00005555555542c5 in _start at nostdlib.c:23
1.2 y 0x00007ffff7fe4f00 <_start>
...
The difference may be down to the availability of debug info for the _start in
the dynamic linker.
Finally, the described scenario on aarch64-linux is not deterministic. The
behavior depends on the dynamic linker being reported as unloaded, which has
been classified as a GLIBC bug, so that might get fixed.
Ideally this test-case would stop at both *_start in the executable and the
dynamic linker, but in absense of a way to specify this reliably (see PR32748),
fix this by making this a temporary breakpoint, ensuring that the breakpoint
will only trigger once.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR testsuite/32743
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32743
Simon Marchi [Wed, 26 Feb 2025 16:52:32 +0000 (11:52 -0500)]
gdb/dwarf: fix failed assertion in dwarf2_find_containing_comp_unit selftest
Commit 2f0521c0d6f6 ("gdb/dwarf: fix signature_type created with nullptr
section") added some asserts in the dwarf2_per_cu_data constructor to
verify that the passed dwarf2_per_bfd and dwarf2_section_info are not
nullptr. However, the dummy dwarf2_per_cu_data objects created in the
dwarf2_find_containing_comp_unit selftests are passed nullptr for those
parameters.
I prefer to keep the asserts in place, as protection for the non-test
code and as self documentation, so fix this by passing some dummy
pointers in the test.
Change-Id: Ic7cdc1b976f7506041b651222234eefc998e473a Reviewed-By: Tom de Vries <tdevries@suse.de>
Simon Marchi [Wed, 26 Feb 2025 16:52:31 +0000 (11:52 -0500)]
gdb/dwarf: pass unit length to dwarf2_per_cu_data constructor
Most of the time, the length of a unit is known when constructing a
dwarf2_per_cu_data or signatured_type. Add a construtor parameter for
it. In the few cases where it isn't, pass 0, which leaves it unset.
Change-Id: I0c8b9683164d3e3f3823ed995f71689a4d17fd96 Reviewed-By: Tom de Vries <tdevries@suse.de>
Indu Bhagat [Wed, 26 Feb 2025 21:50:49 +0000 (13:50 -0800)]
gas: sframe: partially process DWARF unwind info in CFI_escape
CFI_escape is most commonly used to include DWARF expressions in the
unwind information. One may also use CFI_escape to add OS-specific CFI
opcodes. Up until now, SFrame generation process would skip generating
SFrame FDE at the mere sight of a CFI_escape opcode.
Fine tune the handling of CFI_escape for SFrame generation by explicitly
checking for few "harmless" (in context of SFrame generation)
CFI_escape DWARF info:
- DW_CFA_expression affecting registers of no significance to SFrame
stack trace info
- DW_CFA_value_offset affecting registers of no significance to SFrame
stack trace info
Expose the current cfi_escape_data structure in dw2gencfi.c to the
relevant header file to allow SFrame generation APIs to use it too.
Valid unwind info may be split across multiple .cfi_escape directives.
Conversely, it is also allowed to simply put multiple DWARF expressions
and/or operations in a single .cfi_escape directive. Handling all of
these cases correctly will need parsing/processing that is not deemed
worth the effort in context of SFrame generation; We continue to skip
generating SFrame FDE for these cases and warn the user.
In future, SFrame stack trace format may support non-SP/FP as base
register (albeit in limited form). Add an explicit check in
sframe_xlate_do_escape_expr (to test against the current CFA register)
to ensure the functionality continues to work.
Use differentiated warning text in sframe_xlate_do_val_offset to avoid
confusion to the user as the same function is used for handling
.cfi_val_offset and .cfi_escape DW_CFA_val_offset,...
Also, add a common test with DWARF reg 12 which is non SP / FP on x86_64
and aarch64 (and s390x too).
gas/
* gas/dw2gencfi.c (struct cfi_escape_data): Move from ...
* gas/dw2gencfi.h (struct cfi_escape_data): ... to.
* gas/gen-sframe.c (sframe_xlate_do_val_offset): Include string
for .cfi_escape conditionally.
(sframe_xlate_do_escape_expr): New definition.
(sframe_xlate_do_escape_val_offset): Likewise.
(sframe_xlate_do_cfi_escape): Likewise.
(sframe_do_cfi_insn): Handle CFI_escape explicitly.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Add new tests.
* gas/cfi-sframe/cfi-sframe-common-9.d: New test.
* gas/cfi-sframe/cfi-sframe-common-9.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-1.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-2.s: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-empty-3.s: New test.
Charlie Jenkins [Wed, 19 Feb 2025 21:20:18 +0000 (13:20 -0800)]
RISC-V: Fix abort when displaying data and partial instructions
If data is encountered that is not a power of two, dump all of the data with
a .<N>byte directive. The current largest support risc-v instruction length
is 22, so the data over 22 bytes will be displayed by,
.insn, 22, ... + .<N-22>byte.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
Clément Chigot [Mon, 24 Feb 2025 14:00:24 +0000 (15:00 +0100)]
ld/testsuite: add -z separate-code to sframe x86_64 tests
Those tests were generated by a linker having "-z separate-code" on by
default. However, being controlled by a configure option, it can be off
by default. Forcing the option as part of the tests ensures clean
results in both cases.
Tom de Vries [Wed, 26 Feb 2025 06:46:40 +0000 (07:46 +0100)]
[gdb/build] Fix unused var in dwarf2/read.c
On x86_64-linux, with gcc 7.5.0 I ran into a build breaker:
...
gdb/dwarf2/read.c: In function ‘void read_comp_units_from_section()’:
gdb/dwarf2/read.c:4297:31: error: unused variable ‘sig_type_it’ \
[-Werror=unused-variable]
auto [sig_type_it, inserted] = sig_types.emplace (sig_ptr);
^
...
Simon Marchi [Tue, 25 Feb 2025 20:54:56 +0000 (15:54 -0500)]
gdb/dwarf: fix signature_type created with nullptr section
Commit c44ab627b02 ("gdb/dwarf: pass section to dwarf2_per_cu_data
constructor") introduced a regression when using dwp. It can be
reproduced with:
$ make check TESTS="gdb.base/ptype-offsets.exp" RUNTESTFLAGS="--target_board=fission-dwp"
Then, to investigate:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets -ex 'ptype int'
Reading symbols from testsuite/outputs/gdb.base/ptype-offsets/ptype-offsets...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3195:38: runtime error: member call on null pointer of type 'struct dwarf2_section_info'
Commit c44ab627b02 removed the assignment of signatured_type::section
(dwarf2_per_cu_data::section, really) in
fill_in_sig_entry_from_dwo_entry with the justification that the section
was already set when constructing the signatured_type. Well, that was
true except for one spot in lookup_dwp_signatured_type which passes a
nullptr section to add_type_unit.
Fix that by passing the section to add_type_unit in that one spot. This
is the same section that would have been set by
fill_in_sig_entry_from_dwo_entry before.
Add some asserts in the dwarf2_per_cu_data constructor to verity that
the passed dwarf2_per_bfd and dwarf2_section_info are non-nullptr.
Change-Id: If27dae6b4727957c96defc058c7e4be31472005b
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32739 Co-Authored-By: Tom de Vries <tdevries@suse.de> Approved-By: Tom Tromey <tom@tromey.com>
This motivated me to convert the dwarf2_per_bfd::signatured_types hash
table to a gdb::unordered_set. This allows finding an entry by simply
passing the signature (an integer) and removes the need to create dummy
signatured_type objects.
There is one small unfortunate pessimization:
lookup_dwo_signatured_type, for instance, does a lookup by signature to
find an existing signatured_type. If not found, it adds a new one by
calling add_type_unit. The current code passes down the slot where to
put the new element, avoiding an extra hash when inserting the new
signatured_type. With the new code, I don't see a way to do that. This
is probably negligible, but it bugs me. If we used a map of signature
-> signatured_type, I would see a way, but then it would waste space.
I see one change in behavior, that is not really important IMO. In
read_comp_units_from_section, if duplicate signature type entries are
detected, the code prior to this patch overwrites the existing
signatured_type in the hash table with the new one. With this patch,
the existing signatured_type is kept: the call to emplace does not
insert the value if an existing equal value exists.
Other than that, no behavior change expected.
Change-Id: I0bef1b49cc63dbdf4e32fa9d4ea37f83025efc3e Approved-By: Tom Tromey <tom@tromey.com>
projects / thirdparty / binutils-gdb.git / log
