This patch started life as a relatively simple change to fix some
unimportant objcopy memory leaks, but expanded into a larger patch
when I was annoyed by the awkwardness of passing data when using
bfd_map_over_sections. A simple loop over sections is much more
convenient, and we really don't need the abstraction layer. Sections
in a list isn't going to disappear any time soon.
The patch also removes use of the global "status" variable by all but
the top-level functions called from main.
* objcopy.c (filter_symbols): Return success as a bool. Pass
symcount as a pointer, updated on return.
(merge_gnu_build_notes): Similarly return a bool and add newsize
param with updated smaller section size.
(setup_bfd_headers): Return bool success rather than setting
"status" on failure.
(setup_section): Likewise.
(copy_relocations_in_section, copy_section): Likewise, and adjust
params.
(mark_symbols_used_in_relocations): Likewise, and free memory
on failure path. Don't call bfd_fatal.
(get_sections): Delete function.
(copy_object): Don't use bfd_map_over_sections, instead use a
loop allowing easy detection of failure status. Free memory on
error paths.
(copy_archive): Return bool success rather than setting "status"
on failure.
(copy_file): Set "status" here.
* testsuite/binutils-all/strip-13.d: Adjust to suit.
The logic is same as a71d876801 ("aarch64: Add DT_RELR support").
As LoongArch does not have -z dynamic-undefined-weak, we don't need to
consider UNDEFWEAK_NO_DYNAMIC_RELOC.
The linker relaxation adds another layer of complexity. When we delete
bytes in a section during relaxation, we need to fix up the offset in
the to-be-packed relative relocations against this section.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
I think FILE symbols are special, and I can't see why anyone would
want them to be made global. The fact that no one has reported this
bug since commit 7b4a0685e8 in 2005 supports that claim.
PR 31941
* objcopy.c (filter_symbols): Don't allow BSF_FILE symbols to
be made global.
Previously objcopy had to be run twice in order to make a local symbol
weak, first once to globalize it, and once again to mark it as weak.
* objcopy.c (filter_symbols): Weaken symbols after making
local/global changes.
* testsuite/binutils-all/symbols-5.d,
* testsuite/binutils-all/symbols-5.s: New test.
We should set BFD_DECOMPRESS to decompress sections unless dumping the
section contents when reading build-id debuglink.
PR binutils/31925
* objdump.c (open_debug_file): Set BFD_DECOMPRESS to decompress
sections unless dumping the section contents.
* testsuite/binutils-all/objdump.exp (test_build_id_debuglink):
Add a compress option.
Run test_build_id_debuglink with none and zlib.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Files named *.0 are somewhat odd for testsuite expectations. Rename the
one such file to *.r with a suitable base name suffix, and have its
sibling follow suit in this latter regard.
Implement a helper to construct a relative path between two locations in
the filesystem, for example to make a path from the source to the object
directory for the case where a tool has been set up to look at a given
path and there is a need to point it elsewhere, but an absolute path
will not work. The helper works on normalized paths internally, so the
result is correct even in the presence of symlinks as intermediate path
components.
So given "/path/to/src/gas/testsuite/gas/all" as the FROM argument and
then "/path/to/obj/gas/testsuite/tmpdir/none.s" as the TO argument the
helper will return "../../../../../obj/gas/testsuite/tmpdir/none.s" in
the absence of symlinks.
In some cases using section names instead of symbol names for
displaying an address is more useful.
If the symbol falls outside the section where the address is
then likely it is not useful to display the address relative to.
And if symbols are stripped from a binary then printing the
section that contains the address is more useful than printing
<no sym>.
Filter symbols before binary searching for the right symbol to display
for a given address, such that only displayable symbols are present and
at most one per address.
The current logic does not handle multiple symbols for the same address
well if some of them are empty, the selected symbol is not stable with
respect to an unrelated symbol table change and on aarch64 often mapping
symbols are displayed which is not useful.
Filtering solves these problems at the cost of a linear scan of the
sorted symbol table.
The heuristic to select the best symbol likely could be improved, this
patch aims to improve symbol display for RELR without complex logic
such that the output is useful and stable for ld tests.
When printing a DW_MACRO_define_strx entry in a .debug_macro.dwo section, we
run into:
...
DW_MACRO_define_strx lineno : 0 macro : <no .debug_str_offsets section>
...
Fix this in display_debug_macro by passing the correct dwo argument to a
fetch_indexed_string call.
That works fine for readelf -w, with with readelf -wm we have:
...
DW_MACRO_define_strx lineno : 0 macro : <no .debug_str_offsets.dwo section>
...
Fix this in display_debug_macro by doing load_debug_section_with_follow for
str_dwo / str_index_dwo sections instead of str / str_index sections when
handling .debug_macro.dwo.
PR 31735
When compiling a hello world with dwarf4 split dwarf:
...
$ gcc -gdwarf-4 -gsplit-dwarf hello.c -save-temps -dA
...
we have in a-hello.s these three initial entries in .debug_str_offsets:
...
.section .debug_str_offsets.dwo,"e",@progbits
.4byte 0 // indexed string 0x0: short int
.4byte 0xa // indexed string 0x1: /home/vries/binutils
.4byte 0x1f // indexed string 0x2: main
...
but "readelf -ws a.out" starts at the third entry:
...
Contents of the .debug_str_offsets.dwo section (loaded from a-hello.dwo):
Length: 0x30
Index Offset [String]
0 00000000 main
...
This is a regression since commit 407115429b ("Modified changes for
split-dwarf and dwarf-5."), which introduced a variable
debug_str_offsets_hdr_len in display_debug_str_offsets.
Fix this by setting display_debug_str_offsets to 0 for the dwarf4 case.
PR 31734
The fuzzers found a hole. bfd_section_size_insane doesn't check
!SEC_HAS_CONTENTS sections against file size for obvious reasons,
which allows fuzzed debug sections to be stupidly large. Real debug
sections of course always have contents.
PR 31692
* objdump.c (load_specific_debug_section): Don't allow sections
without contents.
coff_section_data() and elf_section_data() use the same underlying
field. The pointer being non-NULL therefore isn't sufficient to know
that pei_section_data() can validly be used on the incoming object.
Apparently in 64-bit-host builds the resulting memory corruption is
benign, whereas in 32-bit-host builds a segmentation fault occurs upon
de-referencing pei_section_data()'s return value.
I'm retiring from IBM, and Geoff hasn't been active for a very long
time.
* MAINTAINERS (ppc): Remove myself and Geoff Keating. Add
Geoff to past maintainers.
Use long with bfd_copy_private_symbol_data to fix
.../binutils/objcopy.c: In
function ‘copy_object’:
.../binutils/objcopy.c:3383:17: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘long int’ [-Werror=sign-compare]
3383 | for (i = 0; i < symcount; i++)
| ^
on 32-bit hosts.
PR binutils/14493
* objcopy.c (copy_object): Use long with
bfd_copy_private_symbol_data.
This lets you examine CTF where the parent and child dicts are in entirely
different sections, rather than in a CTF archive with members with different
names. The linker doesn't emit ELF objects structured like this, but some
third-party linkers may; it's also useful for objcopy-constructed files
in some cases.
(This is what the objdump --ctf-parent option used to do before commit
80b56fad5c in 2021. The new semantics of that option are much more
useful, but that doesn't mean the old ones are never useful at all, so let's
bring them back.)
(I was specifically driven to add this by DTrace's obscure "ctypes" and
"dtypes" options, which dump its internal, dynamically-generated dicts out
to files for debugging purposes: there are two, one the parent of the other.
Since they're in two separate files rather than a CTF archive and we have no
tools that paste files together into archives, objdump wouldn't show them --
and even pasting them together into an ELF executable with objcopy didn't
help, since objdump had no options that could be used to look in specific
sections for the parent dict. With --ctf-parent-section, this sort of
obscure use case becomes possible again. You'll never need it for the
output of the normal linker.)
binutils/
* doc/ctf.options.texi: Add --ctf-parent-section=.
* objdump.c (dump_ctf): Implement it.
(dump_bfd): Likewise.
(main): Likewise.
I don't think any of these can overflow, but since all of the
expressions I'm editing here are inside a while loop with condition
addr_offset < stop_offset, this change makes it more obvious that they
can't overflow.
* objdump.c (disassemble_bytes): Calculate octet expressions
involving both addr_offset and stop_offset by first
subtracting addr_offset from stop_offset.
Given that the disassembler should never abort when decoding
(potentially random) data, assertion statements in the
`get_*reg_qualifier_from_value' function family prove problematic.
Consider the random 32-bit word W, encoded in a data segment and
encountered on execution of `objdump -D <obj_name>'.
If:
(W & ~opcode_mask) == valid instruction
Then before `print_insn_aarch64_word' has a chance to report the
instruction as potentially undefined, an attempt will be made to have
the qualifiers for the instruction's register operands (if any)
decoded. If the relevant bits do not map onto a valid qualifier for
the matched instruction-like word, an abort will be triggered and the
execution of objdump aborted.
As this scenario is perfectly feasible and, in light of the fact that
objdump must successfully decode all sections of a given object file,
it is not appropriate to assert in this family of functions.
Therefore, we add a new pseudo-qualifier `AARCH64_OPND_QLF_ERR' for
handling invalid qualifier-associated values and re-purpose the
assertion conditions in qualifier-retrieving functions to be the
predicate guarding the returning of the calculated qualifier type.
If the predicate fails, we return this new qualifier and allow the
caller to handle the error as appropriate.
As these functions are called either from within
`aarch64_extract_operand' or `do_special_decoding', both of which are
expected to return non-zero values, it suffices that callers return
zero upon encountering `AARCH64_OPND_QLF_ERR'.
Ar present the error presented in the hypothetical scenario has been
encountered in `get_sreg_qualifier_from_value', but the change is made
to the whole family to keep the interface consistent.
Bug: https://sourceware.org/PR31595
