| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
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.
|
|
Fix yet another crash, this one with a fuzzed function symbol size.
The patch also corrects objdump behaviour when both --disassemble=sym
and --stop-address=value are given. Previously --disassemble=sym
overrode --stop-address, now we take the lower of the stop-address
value and the end of function.
* objdump.c (disassemble_section): Sanity check ELF st_size.
|
|
When the linker sees an input object containing nothing but IR during
rescan, it should ignore it (LTO phase is over). But if the input object
is a fat IR object, which has non-IR code as well, it should be used to
resolve references as if it did not contain any IR at all. This patch
adds lto_type to bfd and linker avoids claiming a fat IR object if no IR
object should be claimed.
bfd/
PR ld/23935
* archive.c (_bfd_compute_and_write_armap): Check bfd_get_lto_type
instead of lto_slim_object.
* elflink.c (elf_link_add_object_symbols): Likewise.
* bfd.c (bfd_lto_object_type): New.
(bfd): Remove lto_slim_object and add lto_type.
(bfd_get_lto_type): New function.
* elf.c (lto_section): Removed.
(_bfd_elf_make_section_from_shdr): Don't set lto_slim_object.
* format.c: (lto_section): New.
(bfd_set_lto_type): New function.
(bfd_check_format_matches): Call bfd_set_lto_type.
* bfd-in2.h: Regenerated.
binutils/
PR ld/23935
* nm.c (display_rel_file): Check bfd_get_lto_type instead of
lto_slim_object.
ld/
PR ld/23935
* ldmain.c (add_archive_element): Don't claim a fat IR object if
no IR object should be claimed.
* testsuite/ld-plugin/lto.exp (pr20103): Adjust fat IR test.
Add PR ld/23935 test.
* testsuite/ld-plugin/pr23935a.c: New file.
* testsuite/ld-plugin/pr23935b.c: Likewise.
|
|
If a BFD user is making use of a function like
bfd_get_section_contents to read a section into a pre-allocated
buffer, then that BFD user might also want to make use of
_bfd_section_size_insane prior to allocating the buffer they intend to
use in order to validate that the buffer size that plan to allocate is
sane.
This commit makes _bfd_section_size_insane public, by renaming it to
bfd_section_size_insane.
I've updated the existing uses within bfd/, I don't believe this
function is used outside of bfd/ currently.
One place that I plan to make use of this function is in
gdb/gdb_bfd.c, in the function gdb_bfd_get_full_section_contents.
This change isn't included in this commit, but will come later if/when
this has been merged into bfd.
There should be no change in behaviour after this commit.
bfd/
* bfd-in2.h (bfd_section_size_insane): Add declaration.
* compress.c (bfd_get_full_section_contents): Update for new name
of _bfd_section_size_insane.
(bfd_init_section_compress_status): Likewise.
* dwarf2.c (read_section): Likewise.
(_bfd_dwarf2_slurp_debug_info): Likewise.
* libbfd.h (_bfd_section_size_insane): Remove declaration.
* section.c (_bfd_section_size_insane): Rename to ...
(bfd_section_size_insane): ... this.
binutils/
* readelf.c (uncompress_section_contents): Update comment to
account for new name of _bfd_section_size_insane.
|
|
PR 31469
|
|
with a corrupt entry offset.
PR 31456
|
|
Since ar can be built defaulting to deterministic mode, tests which
expect non-deterministic behaviour need to explicitly set the U flag.
The non-deterministic member test expects SOURCE_DATE_EPOCH to not be
set; this documents that. Unconditionally unsetting the variable
causes issues in test infrastructure (which expects unsetenv to only
be called on variables which are already set).
Signed-off-by: Stephen Kitt <steve@sk2.org>
|
|
|
|
Base and index register 0 have no effect in address computation:
"A value of zero in the B [base] or X [index] field specifies that no
base or index is to be applied, and, thus, general register 0 cannot be
designated as containing a base address or index."
IBM z/Architecture Principles of Operation [1], chapter "Organization",
section "General Registers".
Index register 0 is omitted in the s390 disassembly. Base register 0 is
omitted in D(B), D(L,B) and D(X,B) - the latter only if the index
register is zero.
To make it more apparent print base register 0 as "0" instead of "%r0",
whenever it would still be printed in the disassembly.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
opcodes/
* s390-dis.c: Print base register 0 as "0" in disassembly.
binutils/
* NEWS: Mention base register 0 now being printed as "0" in s390
disassembly.
gas/
* testsuite/gas/s390/zarch-base-index-0.d: Update test case
output verification patterns to accept "0" as base base
register due to disassembler output format change.
* gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise.
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
|
|
Next to code using %ymm<N> or %zmm<N> it is more natural to have .cfi_*
directives also reference those, not the corresponding %xmm<N>. Accept
their names as kind of aliases, i.e. resolving to the same numbers.
While extending the respective 64-bit testcase, also add %bnd<N> there
(should have happened right with 633789901c83 ["x86-64: Dwarf2 register
numbers for %bnd<N>"], sorry), requiring binutils/dwarf.c to be adjusted
accordingly as well.
|
|
the documentation
|
|
binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_SYSCALLS segment type.
include * elf/common.h (PT_OPENBSD_SYSCALLS): Define.
|
|
binutils/
* doc/binutils.texi (PowerPC -M option): Mention power11 and pwr11.
gas/
* config/tc-ppc.c: (md_show_usage): Mention -mpower11 and -mpwr11.
* doc/c-ppc.texi: Likewise.
opcodes/
* ppc-dis.c (ppc_opts): Add "power11" and "pwr11" entries.
(powerpc_init_dialect): Default to "power11".
|
|
On big endian hosts (eg. s390x) the windmc tool fails to parse even
trivial files:
$ cat test.mc
;
$ ./binutils/windmc ./test.mc
In test.mc at line 1: parser: syntax error.
In test.mc at line 1: fatal: syntax error.
The tool starts by reading the input as Windows CP1252 and then
converting it internally into an array of UTF-16LE, which it then
processes as an array of unsigned short (typedef unichar).
There are lots of ways this is wrong, but in the specific case of big
endian machines the little endian pairs of bytes are byte-swapped.
For example, the ';' character in the input above is first converted
to UTF16-LE byte sequence { 0x3b, 0x00 }, which is then cast to
unsigned short. On a big endian machine the first unichar appears to
be 0x3b00. The lexer is unable to recognize this as the comment
character ((unichar)';') and so parsing fails.
The simple fix is to convert the input to UTF-16BE on big endian
machines (and do the reverse conversion when writing the output).
Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=31283
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
|
|
* objdump.c (disassemble_section): Free rel_ppstart on error path.
|
