| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit de7b90610e9e left a hole in the element checking, explained by
the comment added to _bfd_xcoff_openr_next_archived_file. While
fixing this, tidy some types used to hold unsigned values so that
casts are not needed to avoid signed/unsigned comparison warnings.
Also tidy a few things in xcoff.h.
bfd/
* coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Check
that we aren't pointing back at the last element. Make
filestart a ufile_ptr. Update for xcoff_artdata change.
(_bfd_strntol, _bfd_strntoll): Return unsigned values.
(_bfd_xcoff_slurp_armap): Make off a ufile_ptr.
(add_ranges): Update for xcoff_artdata change.
* libbfd-in.h (struct artdata): Make first_file_filepos a
ufile_ptr.
* libbfd.h: Regenerate.
include/
* coff/xcoff.h (struct xcoff_artdata): Replace min_elt with
ar_hdr_size.
(xcoff_big_format_p): In the !SMALL_ARCHIVE case return true
for anything but a small archive.
|
|
20+ years is long enough to warn.
* bfd-in.h (bfd_read, bfd_write): Don't define
(_bfd_warn_deprecated): Don't declare.
* bfd-in2.h: Regenerate.
* libbfd.c (_bfd_warn_deprecated): Delete.
|
|
* bfd-in.h (bfd_byte): Typedef as int8_t.
(flagword): Typedef as uint32_t.
(bfd_vma, bfd_signed_vma, bfd_size_type, symvalue): Use stdint
types in !BFD64 case.
* bfd-in2.h: Regenerate.
|
|
|
|
|
|
Ventana Micro has published the specification for their
XVentanaCondOps ("conditional ops") extension at
https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf
which contains two new instructions
- vt.maskc
- vt.maskcn
that can be used in constructing branchless sequences for
various conditional-arithmetic, conditional-logical, and
conditional-select operations.
To support such vendor-defined instructions in the mainline binutils,
this change also adds a riscv_supported_vendor_x_ext secondary
dispatch table (but also keeps the behaviour of allowing any unknow
X-extension to be specified in addition to the known ones from this
table).
As discussed, this change already includes the planned/agreed future
requirements for X-extensions (which are likely to be captured in the
riscv-toolchain-conventions repository):
- a public specification document is available (see above) and is
referenced from the gas-documentation
- the naming follows chapter 27 of the RISC-V ISA specification
- instructions are prefixed by a vendor-prefix (vt for Ventana)
to ensure that they neither conflict with future standard
extensions nor clash with other vendors
bfd/ChangeLog:
* elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext.
(riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS.
gas/ChangeLog:
* doc/c-riscv.texi: Add section to list custom extensions and
their documentation URLs.
* testsuite/gas/riscv/x-ventana-condops.d: New test.
* testsuite/gas/riscv/x-ventana-condops.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h Add vt.maskc and vt.maskcn.
* opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS.
opcodes/ChangeLog:
* riscv-opc.c: Add vt.maskc and vt.maskcn.
Series-version: 1
Series-to: binutils@sourceware.org
Series-cc: Kito Cheng <kito.cheng@sifive.com>
Series-cc: Nelson Chu <nelson.chu@sifive.com>
Series-cc: Greg Favor <gfavor@ventanamicro.com>
Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>
|
|
|
|
|
|
|
|
The testcase managed to trigger creation of a wild pointer in
coff_slurp_symbol_table. Stop that happening, and fix an unrelated
problem I happened to see in bfd_coff_get_syment.
* coff-bfd.c (bfd_coff_get_syment): Clear fix_value after
converting n_value from a pointer to an index.
* coffcode.h (coff_slurp_symbol_table <C_BSTAT>): Sanity check
symbol value before converting to a pointer.
|
|
|
|
If the triple is mipsisa32r6* or mipsisa64r6*, ld/as should output
r6 objects by default.
The triples with vendor `img` should do same.
The examples include:
as xx.s -o xx.o
ld -r -b binary xx.dat -o xx.o
|
|
For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
used as the cpu name in triple.
Let's recognize them by `mips*64*(el)`.
For 64bit Ports, like Debian's mips64el and mips64r6el ports,
`gnuabi64` is used as the abi section.
Let's use N64 abi by default for the triple with gnuabi64.
|
|
|
|
|
|
A semicolon was missing and "name" needs to be pointer-to-const. While
adding "const" there, also add it for "sec".
|
|
This should be the first related issue, which posted in riscv-gnu-toolchain,
https://github.com/riscv-collab/riscv-gnu-toolchain/issues/497
If the output sections are not between gp and the symbol, then their alignments
shouldn't affect the gp relaxation. However, this patch improves this idea
even more, it limits the range to the gp+-2k, which means only the output
section which are in the [gp-2K, gp+2K) range need to be considered.
Even if the output section candidates may be different for each relax passes,
the symbol that can be relaxed ar this round will not be truncated at next
round. That is because this round you can do relaxation which means that the
section where the symbol is located is within the [gp-2K, gp+2K) range, so all
the output section alignments between them should be considered. In other
words, if the alignments between them may cause truncated, then we should
already preserve the size and won't do the gp relaxation this time.
This patch can resolve the github issue which mentioned above, and also passed
all gcc/binutils regressions of riscv-gnu-toolchain, so should be worth and
safe enough to commit.
Originally, this patch also do the same optimization for the call relaxations,
https://sourceware.org/pipermail/binutils/2022-October/123918.html
But just in case there is something that has not been considered, we only
deal with the gp relaxation at this time.
bfd/
* elfnn-riscv.c (riscv_elf_link_hash_table): Added new bfd_vma,
max_alignment_for_gp. It is used to record the maximum alignment of
the output sections, which are in the [gp-2K, gp+2k) range.
(riscv_elf_link_hash_table_create): Init max_alignment_for_gp to -1.
(_bfd_riscv_get_max_alignment): Added new parameter, gp. If gp is
zero, then all the output section alignments are possible candidates;
Otherwise, only the output sections which are in the [gp-2K, gp+2K)
range need to be considered.
(_bfd_riscv_relax_lui): Called _bfd_riscv_get_max_alignment with the
non-zero gp if the max_alignment_for_gp is -1.
(_bfd_riscv_relax_pc): Likewise.
(_bfd_riscv_relax_section): Record the first input section, so that
we can reset the max_alignment_for_gp for each repeated relax passes.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/relax-max-align-gp.*: New testcase. It fails
without this patch.
|
|
rs6000-coff archives use a linked list of file offsets, where each
element points to the next element. The idea is to allow updating of
large archives quickly without rewriting the whole archive. (binutils
ar does not do this.) Unfortunately this is an easy target for
fuzzers to create an archive that will cause ar or any other tool
processing archives to hang. I'd implemented guards against pointing
back to the previous element, but of course that didn't last long.
So this patch implements a scheme to keep track of file offset ranges
used by elements as _bfd_read_ar_hdr is called for each element. See
the add_range function comment. I needed a place to stash the list,
so chose the obvious artdata.tdata backend extension to archive's
tdata, already used by xcoff. That involved a little cleanup, because
while it would be possible to continue using different artdata.tdata
for the big and small archives, it's nicer to use a union.
If anyone is concerned this list of element ranges might grow large
and thus significantly slow down the tools, adjacent ranges are
merged. In fact something like "ar t" will only ever have one range
on xcoff archives generated by binutils/ar. I agree there might still
be a problem with ld random element access via the armap.
include/
* coff/xcoff.h (SIZEOF_AR_FILE_HDR): Use sizeof.
(SIZEOF_AR_FILE_HDR_BIG, SIZEOF_AR_HDR, SIZEOF_AR_HDR_BIG): Likewise.
(struct ar_ranges, struct xcoff_artdata): New.
(x_artdata): Define.
(xcoff_big_format_p): Rewrite.
(xcoff_ardata, xcoff_ardata_big): Delete.
bfd/
* coff-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(_bfd_xcoff_archive_p): Adjust artdata.tdata allocation.
(add_range): New function.
(_bfd_xcoff_read_ar_hdr): Use it here. Fix memory leak.
(_bfd_xcoff_openr_next_archived_file): Remove old sanity
checks. Set up range for header.
(xcoff_write_archive_contents_old): Make the temporary
artdata.tdata used here to pass info down to
_bfd_compute_and_write_armap a struct xcoff_artdata.
(xcoff_write_archive_contents_big): Likewise.
* coff64-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(xcoff64_archive_p): Adjust artdata.tdata allocation.
|
|
This element is unused. Ideally we'd be moving archive_head and
other archive specific fields from struct bfd to here, but that's a
much larger change than this little bit of cleanup.
* libbfd-in.h (struct artdata): Delete archive_head.
* libbfd.h: Regenerate.
* archive.c,
* coff-rs6000.c,
* coff64-rs6000.c: Delete comments mentioning artdata archive_head.
|
|
|
|
|
|
Segmentation fault
FAIL: pr22269-1 (static pie undefined weak)
and others running "visibility (hidden undef)" tests
No code has any right to access bfd_link_hash_entry u.def without
first checking the type, and SYMBOL_REFERENCES_LOCAL isn't sufficient.
* elf32-sh.c (sh_elf_finish_dynamic_symbol): Don't use relative
relocs in GOT unless symbol is defined.
|
|
Do I care about out of memory conditions triggered by fuzzers? Not
much. Your operating system ought to be able to handle it by killing
the memory hog. Oh well, this one was an element of a coff-alpha
archive that said it was a little less that 2**64 in size. The
coff-alpha compression scheme expands at most 8 times, so we can do
better in bfd_get_file_size.
* bfdio.c (bfd_get_file_size): Assume elements in compressed
archive can only expand a maximum of eight times.
* coffgen.c (_bfd_coff_get_external_symbols): Sanity check
size of symbol table agains file size.
|
|
* ecoff.c (_bfd_ecoff_slurp_symbolic_info): Zero terminate
string sections.
|
|
|
|
|
|
PR 30142
* peXXigen.c (_bfd_XXi_swap_scnhdr_out): Do not force the .rsrc section to be writeable.
* rescoff.c (write_coff_file): Add the SEC_READONLY flag to the .rsrc section.
|
|
|
|
|
|
|
|
|
|
AOUT and COFF targets set symcount and start_address in their object_p
functions. If these are used anywhere then it would pay to save and
restore them so that a successful match gets the values expected
rather than that for a later unsuccessful target match.
* format.c (struct bfd_preserve): Move some fields. Add
symcount, read_only and start_address.
(bfd_preserve_save): Save..
(bfd_preserve_restore): ..and restore..
(bfd_reinit): ..and zero new fields.
|
|
The last patch wasn't quite correct. bfd_preserve_restore also needs
to handle an in-memory to file backed transition, seen in a testcase
ILF object matching both pei-arm-little and pei-arm-wince-little.
There the first match is saved in preserve_match, and restored at the
end of the bfd_check_format_matches loop making the bfd in-memory. On
finding more than one match the function wants to restore the bfd back
to its original state with another bfd_preserve_restore call before
exiting with a bfd_error_file_ambiguously_recognized error.
It is also not correct to restore abfd->iostream unless the iovec
changes. abfd->iostream is a FILE* when using cache_iovec, and if
the file has been closed and reopened the iostream may have changed.
* format.c (io_reinit): New function.
(bfd_reinit, bfd_preserve_restore): Use it.
|
|
|
|
Introduce `static const struct mips_mach_extension mips_mach_32_64[]`
and `mips_mach_extends_32_64 (unsigned long base, unsigned long extension)`,
to make mipsisa32 and mipsisa64 interlink more systemtic.
Normally, the ISA mipsisa64rN has two subset: mipsisa64r(N-1) and
mipsisa32rN. `mips_mach_extensions` can hold only mipsisa64r(N-1),
so we need to introduce a new instruction `mips_mach_32_64`, which holds the pair 32vs64.
Note: R6 is not compatible with pre-R6.
bfd/ChangeLog:
* elfxx-mips.c (mips_mach_extends_p): make mipsisa32 and
mipsisa64 interlink more systematic.
(mips_mach_32_64): new struct added.
(mips_mach_extends_32_64): new function added.
|
|
This is a fuzzing PR, with a testcase involving a SHF_ALLOC and
SHF_COMPRESSED SHT_RELA section, ie. a compressed dynamic reloc
section. BFD doesn't handle compressed relocation sections, with most
of the code reading relocs using sh_size (often no bfd section is
created) but in the case of SHF_ALLOC dynamic relocs we had some code
using the bfd section size. This led to a mismatch, sh_size is
compressed, size is uncompressed, and from that some uninitialised
memory. Consistently using sh_size is enough to fix this PR, but I've
also added tests to exclude SHF_COMPRESSED reloc sections from
consideration.
PR 30362
* elf.c (bfd_section_from_shdr): Exclude reloc sections with
SHF_COMPRESSED flag from normal reloc processing.
(_bfd_elf_get_dynamic_reloc_upper_bound): Similarly exclude
SHF_COMPRESSED sections from consideration. Use sh_size when
sizing to match slurp_relocs.
(_bfd_elf_canonicalize_dynamic_reloc): Likewise.
(_bfd_elf_get_synthetic_symtab): Use NUM_SHDR_ENTRIES to size
plt relocs.
* elf32-arm.c (elf32_arm_get_synthetic_symtab): Likewise.
* elf32-ppc.c (ppc_elf_get_synthetic_symtab): Likewise.
* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
* elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise.
|
|
Except it isn't out of bounds because space for a larger array has
been allocated.
* dwarf2.c (struct trie_leaf): Make ranges a C99 flexible array.
(alloc_trie_leaf, insert_arange_in_trie): Adjust sizing.
|
|
If pe_ILF_object_p succeeds, pe_ILF_build_a_bfd will have changed the
bfd from being file backed to in-memory. This can have unfortunate
results for targets checked by bfd_check_format_matches after that
point as they will be matching against the created in-memory image
rather than the file. bfd_preserve_restore also has a problem if it
flips the BFD_IN_MEMORY flag, because the flag affects iostream
meaning and should be set if using _bfd_memory_iovec. To fix these
problems, save and restore iostream and iovec along with flags, and
modify bfd_reinit to make the bfd file backed again. Restoring the
iovec and iostream allows the hack in bfd_reinit keeping BFD_IN_MEMORY
(part of BFD_FLAGS_SAVED) to be removed.
One more detail: If restoring from file backed to in-memory then the
bfd needs to be forcibly removed from the cache lru list, since after
the bfd becomes in-memory a bfd_close will delete the bfd's memory
leaving the lru list pointing into freed memory.
* cache.c (bfd_cache_init): Clear BFD_CLOSED_BY_CACHE here..
(bfd_cache_lookup_worker): ..rather than here.
(bfd_cache_close): Comment.
* format.c (struct bfd_preserve): Add iovec and iostream fields.
(bfd_preserve_save): Save them..
(bfd_preserve_restore): ..and restore them, calling
bfd_cache_close if the iovec differs.
(bfd_reinit): Add preserve param. If the bfd has been flipped
to in-memory, reopen the file. Restore flags.
* peicode.h (pe_ILF_cleanup): New function.
(pe_ILF_object_p): Return it.
* bfd.c (BFD_FLAGS_SAVED): Delete.
* bfd-in2.h: Regenerate.
|
|
|
|
The bfd_elf_hash loop is taken straight from the sysV document, but it
is poorly optimized. This refactoring removes about 5 x86 insns from
the 15 insn loop.
1) The if (..) is meaningless -- we're xoring with that value, and of
course xor 0 is a nop. On x86 (at least) we actually compute the xor'd
value and then cmov. Removing the if test removes the cmov.
2) The 'h ^ g' to clear the top 4 bits is not needed, as those 4 bits
will be shifted out in the next iteration. All we need to do is sink
a mask of those 4 bits out of the loop.
3) anding with 0xf0 after shifting by 24 bits can allow betterin
encoding on RISC ISAs than masking with '0xf0 << 24' before shifting.
RISC ISAs often require materializing larger constants.
bfd/
* elf.c (bfd_elf_hash): Refactor to optimize loop.
(bfd_elf_gnu_hash): Refactor to use 32-bit type.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Having been irritated by seeing bfd/elf{32,64}-aarch64.c to be re-
generated in x86-only builds, I came across 769a27ade588 ("Re: bfd
BLD-POTFILES.in dependencies"). I think this went slightly too far, as
outside of maintainer mode dependencies will cause the subset of files
to be (re-)generated which are actually needed for the build.
Generating them all is only needed when wanting to update certain files
under bfd/po/, i.e. in maintainer mode.
In the course of looking around in an attempt to try to understand how
things are meant to work, I further noticed that ld has got things
slightly wrong too: BLD-POTFILES.in depending on $(BLD_POTFILES) isn't
quite right (the output doesn't change when any of the enumerated files
changes; it's the mere presence which matters); like in bfd it looks
like we would better extend BUILT_SOURCES accordingly.
Furthermore it became apparent that ld fails to enumerate the .c files
generated from the .l and .y ones. While in their absence it was benign
whether translatable strings in the source files were actually marked as
such, this now becomes relevant. Mark respective strings at the same
time, but skipping ones which look to be of interest for debugging
purposes only (e.g. such used by printf() enclosed in #ifdef TRACE).
|
|
|
|
|
