| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
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.
The new output looks like this:
[...]
Symbol table:
[ 1] circular1: <0><1> DW_TAG_module DW_IDX_compile_unit=1 DW_IDX_die_offset=<0x19> DW_IDX_GNU_language=19
[...]
[ 6] found: <0x28><2> DW_TAG_subprogram DW_IDX_compile_unit=1 DW_IDX_die_offset=<0x38> DW_IDX_GNU_language=19 DW_IDX_parent=<0x0>
Here you can see that DW_IDX_parent=0 refers to "circular1: <0>".
|
|
I noticed that cooked-index.h still refers to a vector of parent maps,
but the code itself actually uses a parent_map here.
|
|
|
|
* ecoff.c (_bfd_ecoff_write_armap): Don't use statbuf.st_mtime
if stat call returns non-zero. Use ARMAP_TIME_OFFSET rather
than its expansion.
|
|
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.
|
|
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.
|
|
Most of these were not needed, and moving a few functions around
removes the need for any.
|
|
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.
|
|
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.
|
|
The parameter `abfd` is always the same as `this->obfd`, there is no
need to pass it as a parameter.
Change-Id: If7ad58ad4efdf6b070cbf2b8a73436bd8b452fa6
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Expressions.html
|
|
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
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Address-Locations.html
|
|
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.
...
In Pascal and Modula-2, this is &function.
...
I tried "break *&function" for Pascal and Modula-2, and this doesn't work,
while "break *function" works fine.
Fix this by updating the documentation to reflect actual behaviour.
Approved-By: Eli Zaretskii <eliz@gnu.org>
PR gdb/32754
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32754
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Address-Locations.html
|
|
clangd reports them as unused.
Change-Id: I50a3c13db128ffe1630364f707d66a24ce11d352
|
|
clangd reports it as unused.
Change-Id: I636e57747d3c42ce6615a14d4cf5dc115628a73d
|
|
It only add one new CSR: `srmcfg`.
Ref: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0
|
|
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.
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#mapping-symbol
Before this patch, the mapping-x.s was dumped as,
00000000 <.text>:
0: 00000013 nop
4: 0001 .insn 2, 0x0001
6: 0001 .insn 2, 0x0001
Which is caused by the definiation of $x was conflict with the psABI.
|
|
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.
|
|
|
|
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.
Signed-off-by: Richard Allen <rsaxvc@gmail.com>
|
|
|
|
Instead of fixing "somebody miscounted" errors,
this patch combines the core_create_line_syms()
passes, and dynamically expands the ltab buffer.
Reducing the number of passes will make future
optimizations simpler.
Signed-off-by: Richard Allen <rsaxvc@gmail.com>
|
|
Signed-off-by: Richard Allen <rsaxvc@gmail.com>
|
|
Roughly halves the number of bfd_find_nearest_line() calls,
about 40% less time for a few different large ELF files.
Signed-off-by: Richard Allen <rsaxvc@gmail.com>
|
|
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.
Signed-off-by: Richard Allen <rsaxvc@gmail.com>
|
|
Signed-off-by: Richard Allen <rsaxvc@gmail.com>
|
|
|
|
I noticed we quite often use:
bfd_get_filename (per_bfd->obfd)
Add a shortcut for that.
Change-Id: I4e33925a481fd44088386510b01936d38e1d7d38
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This matches the exclusion added to the GCC .gitignore file in 2022.
|
|
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>
|
|
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.
|
|
ctf_archive_next returns an opened dict, which must be closed by the caller.
Thanks to Alan Modra for spotting this.
binutils/
* objdump.c (dump_ctf): Close dict.
* readelf.c (dump_section_as_ctf): Likewise.
|
|
<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>
|
|
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
|
|
I noticed a
// namespace selftests
comment, which doesn't follow our comment formatting convention. I did
a find & replace to fix all the offenders.
Change-Id: Idf8fe9833caf1c3d99e15330db000e4bab4ec66c
|
|
|
|
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>
|
|
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>
|
|
|
|
Pass -z separate-code to ld for -z mark-plt tests to fix:
FAIL: ld-x86-64/mark-plt-1a
FAIL: ld-x86-64/mark-plt-1b
FAIL: ld-x86-64/mark-plt-1c
FAIL: ld-x86-64/mark-plt-1d
FAIL: ld-x86-64/mark-plt-1a-x32
FAIL: ld-x86-64/mark-plt-1b-x32
FAIL: ld-x86-64/mark-plt-1c-x32
FAIL: ld-x86-64/mark-plt-1d-x32
when binutils is configured with --disable-separate-code.
* ld-x86-64/mark-plt-1a-x32.d: Pass -z separate-code to ld.
* ld-x86-64/mark-plt-1a.d: Likewise.
* ld-x86-64/mark-plt-1b-x32.d: Likewise.
* ld-x86-64/mark-plt-1b.d: Likewise.
* ld-x86-64/mark-plt-1c-x32.d: Likewise.
* ld-x86-64/mark-plt-1c.d: Likewise.
* ld-x86-64/mark-plt-1d-x32.d: Likewise.
* ld-x86-64/mark-plt-1d.d: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
|
|
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.
|
|
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>
|
|
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.
|
|
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);
^
...
Fix this by dropping the unused variable.
Tested on x86_64-linux, by completing a build.
|
|
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>
|
