| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
PR 31898
* dwarf.c (display_debug_rnglists_list): Correct fetch of "end"
indexed address. Remove excess parens.
|
|
Tweak commit db335d7e0a so that support_dt_relr returns false for
aarch64*-*-*ilp32.
|
|
Not all aarch64 targets supports dt_relr as this requires some
mechanisms on the OS side.
Adjust support_dt_relr helper and use it in aarch64-elf.exp.
|
|
|
|
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-2
|
|
- AC_AIX, AC_MINIX, and AC_GNU_SOURCE by AC_USE_SYSTEM_EXTENSIONS
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fAIX
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fMINIX-1
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fGNU_005fSOURCE-1
|
|
- AC_HELP_STRING by AS_HELP_STRING
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fHELP_005fSTRING-1
Except for the ifdef in lib-prefix.m4, make the defun of AC_LIB_ARG_WITH
unconditional.
|
|
|
|
invoking src-release.sh
|
|
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.
|
|
|
|
|
|
PR 31687
|
|
PR 31704
|
|
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 407115429b3 ("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
|
|
Finally, update the documentation and add a NEWS item.
|
|
Remove the decoding of the Maverick flag from readelf.
|
|
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.
|
|
PR 31722
|
|
I happened to notice that the binutils manual has a typo in the name
of a command-line option.
|
|
PR 31692
* objdump.c (load_specific_debug_section): Replace bfd_get_size
check with bfd_section_size_insane. Call free_debug_section
after printing error messages. Set section->start NULL when
freeing.
|
|
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.
|
|
relocated
|
|
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.
|
|
|
|
osympp appearing twice here is not a bug.
PR 14493
* objcopy.c (copy_object): Run the symbols through
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
80b56fad5c99a8c9 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
|
|
|
|
|
|
VMA->LMA relationship does not match the relationship of earlier sections in the segment.
PR 31540
|
|
read_bases has a potential null-pointer deref too, and without a
debug_info_p there isn't any point in calling read_bases.
* dwarf.c (process_debug_info): Don't call read_bases when
debug_info_p is NULL.
|
|
|
|
|
|
ubsan: shift exponent 255 is too large for 64-bit type
I should have known oss-fuzz wouldn't be satisfied so easily. The pef
format allows quite silly section alignments in object files.
* objcopy.c (setup_section): Limit shift exponent when checking
vma and lma for alignment.
|
|
|
|
When -fsanitize=address,undefined is used to build, the mmap configure
check failed with
=================================================================
==231796==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x5750c7f6d72b in main /home/alan/build/gas-san/all/bfd/conftest.c:239
Direct leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x5750c7f6d2e1 in main /home/alan/build/gas-san/all/bfd/conftest.c:190
SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 2 allocation(s).
Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP to avoid the sanitizer
configure check failure.
bfd/
* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
binutils/
* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
ld/
* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
libctf/
* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
libsframe/
* configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP.
* Makefile.in: Regenerated.
* aclocal.m4: Likewise.
* configure: Likewise.
|
|
For some reason, these targets are missing although others from the
same family are present. This looks like an oversight.
This enables calling 'make install-dvi' from the top-level build
directory.
|
|
ubsan: left shift of 1 by 31 places cannot be represented in type 'int'
* objcopy.c (setup_section): Avoid undefined behaviour when
checking vma and lma for alignment.
|
|
|
|
|
|
symbols referenced by an instruction.
|
|
flag on PE sections. Add a check for aligned sections not matching their VMAs.
|
|
Given this testcase:
.text
mov $x1,%eax
f1:
mov $f1,%eax
.type f1,@function
.size f1,.-f1
mov $x2,%eax
f2:
mov $f2,%eax
.type f2,@function
.size f2,.-f2+0x1000 #bad size
objdump --reloc --disassemble=f1 prints
00000000 <f1-0x5>:
0: b8 00 00 00 00 mov $0x0,%eax
and objdump --reloc --disassemble=f2 prints
0000000f <f2>:
f: b8 0f 00 00 00 mov $0xf,%eax
10: R_386_32 .text
It seems for f1 we get the insn before f1 and no reloc whereas, post
159daa36fa, f2 is disassembled correctly. Some analysis says that
find_symbol_for_address may return a symbol past the current address,
and reloc skipping is broken. Fix both of these problems.
* objdump.c (disassemble_jumps, disassemble_bytes): Replace
relppp with relpp, ie. don't update caller's rel_pp. Adjust
calls.
(disassemble_section): Skip over relocs inside loop rather
than before loop. Revert 7e538762c2c1. If given a symbol,
don't start disassembling until its address is reached.
Correct end of function calculation.
|
