the offset-to-entry mappings are allocated in blocks, which may
become a bit wasteful in case there are extremely many small
input files or sections. This made it so that a large project
(Qt5WebEngine) didn't build anymore on x86 32bit due to address
space limits. It barely fit into address space before the new
string merging, and then got pushed over the limit by this.
So instead of leaving the waste reallocate the maps to their final
size once known. Now the link barely fits again.
bfd/
* merge.c (record_section): Reallocate offset maps to their
final size.
as the bug report shows we had an overflow in the test if
hash table resizing is needed. Reorder the expression to avoid
that. There's still a bug somewhere in gracefully handling
failure in resizing (e.g. out of memory), but this pushes the
boundary for that occurring somewhen into the future and
immediately helps the reporter.
bfd/
PR ld/31009
* merge.c (NEEDS_RESIZE): New macro avoiding overflow.
(sec_merge_maybe_resize): Use it.
(sec_merge_hash_insert): Ditto.
We decide to emit BTI stubs based on the instruction at the target
location. But PLT code is generated later than the stubs so we always
read 0 which is not a valid BTI.
Fix the logic to special case the PLT section: this is code the linker
generates so we know when it will have BTI.
This avoids BTI stubs in large executables where the PLTs have them
already. An alternative is to never emit BTI stubs for PLTs, instead
use BTI in the PLT if a library gets too big, however that may be
more tricky given the ordering of PLT sizing and stub insertion.
Related to bug 30957.
BTI stub parameters were recomputed even if those were already set up.
This is unnecessary work and leaks the symbol name that is allocated
for the stub.
Input sections are grouped together that can use the same stub area
(within reach) and these groups have a stable id.
Stubs have a name generated from the stub group id and target symbol.
When a relocation requires a stub with a name that already exists, the
stub is reused instead of adding a new one.
For an indirect branch stub another BTI stub may be inserted near the
target to provide a BTI landing pad.
The BTI stub can end up with the same stub group id and thus the same
name as the indirect stub. This happens if the target symbol is within
reach of the indirect branch stub. Then, due to the name collision,
only a single stub was emmitted which branched to itself causing an
infinite loop at runtime.
A possible solution is to just name the BTI stubs differently, but
since in the problematic case the indirect and BTI stub are in the
same stub area, a better solution is to emit a single stub with a
direct branch. The stub is still needed since the caller cannot reach
the target directly and we also want a BTI landing pad in the stub in
case other indirect stubs target the same symbol and thus need a BTI
stub.
In short we convert an indirect branch stub into a BTI stub when the
target is within reach and has no BTI. It is a hassle to change the
symbol of the stub so a BTI stub may end up with *_veneer instead of
*_bti_veneer after the conversion, but this should not matter much.
(Refactoring some of _bfd_aarch64_add_call_stub_entries would be
useful but too much for this bug fix patch.)
The same conversion to direct branch could be done even if the target
did not need a BTI. The stub groups are fixed in the current logic so
linking can fail if too many stubs are inserted and the section layout
is changed too much, but this only happens in extreme cases that can
be reasonably ignored. Because of this the target cannot go out of
reach during stub insertion so the optimization is valid, but not
implemented by this patch for the non-BTI case.
Fixes bug 30930.
The instruction was looked up in the wrong input file (file of branch
source instead of branch target) when optimizing away BTI stubs in
commit 5834f36d93cabf1a8bcc7dd7654141aed3d296bc
bfd: aarch64: Optimize BTI stubs PR30076
This can cause adding BTI stubs when they are not necessary or removing
them when they are (the latter is a correctness issue but it is very
unlikely in practice).
Fixes bug 30957.
In a safety context, it could interesting to track the trampolines being
generated, ensuring there are expected or not.
bfd/ChangeLog:
* elf32-ppc.c (ppc_elf_relax_section): Log branch fixups.
ld/ChangeLog:
* ld.texi (--print-map): Add new item about fixups.
This patch provides some minimal thread-safety to BFD.
The BFD client can request thread-safety by providing a lock and
unlock function. The globals used during BFD creation (e.g.,
bfd_id_counter) are then locked, and the file descriptor cache is also
locked. A function to clean up any thread-local data is now provided
for BFD clients.
* bfd-in2.h: Regenerate.
* bfd.c (lock_fn, unlock_fn): New globals.
(bfd_thread_init, bfd_thread_cleanup, bfd_lock, bfd_unlock): New
functions.
* cache.c (bfd_cache_lookup_worker): Use _bfd_open_file_unlocked.
(cache_btell, cache_bseek, cache_bread, cache_bwrite): Lock
and unlock.
(cache_bclose): Add comment.
(cache_bflush, cache_bstat, cache_bmmap): Lock and unlock.
(_bfd_cache_init_unlocked): New function.
(bfd_cache_init): Use it. Lock and unlock.
(_bfd_cache_close_unlocked): New function.
(bfd_cache_close, bfd_cache_close_all): Use it. Lock and unlock.
(_bfd_open_file_unlocked): New function.
(bfd_open_file): Use it. Lock and unlock.
* doc/bfd.texi (BFD front end): Add Threading menu item.
* libbfd.h: Regenerate.
* opncls.c (_bfd_new_bfd): Lock and unlock.
* po/bfd.pot: Regenerate.
This makes _bfd_error_buf static and adds a way to clear it. I felt
that this made the subsequent patches a little cleaner.
* bfd.c (_bfd_error_buf): Now static.
(bfd_set_input_error): Use _bfd_clear_error_data.
(_bfd_clear_error_data): New function.
(bfd_init): Use _bfd_clear_error_data.
* libbfd.h: Regenerate.
* opncls.c (bfd_close_all_done): Use _bfd_clear_error_data.
* po/bfd.pot: Regenerate.
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html
Contributors:
Mary Bennett <mary.bennett@embecosm.com>
Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Pietra Ferreira <pietra.ferreira@embecosm.com>
Charlie Keaney
Jessica Mills
Craig Blackmore <craig.blackmore@embecosm.com>
Simon Cook <simon.cook@embecosm.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
Helene Chelin <helene.chelin@embecosm.com>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvalu`
instruction class.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Added the necessary
operands for the extension.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Noted XCValu as an additional ISA extension
for CORE-V.
* testsuite/gas/riscv/cv-alu-boundaries.d: New test.
* testsuite/gas/riscv/cv-alu-boundaries.l: New test.
* testsuite/gas/riscv/cv-alu-boundaries.s: New test.
* testsuite/gas/riscv/cv-alu-fail-march.d: New test.
* testsuite/gas/riscv/cv-alu-fail-march.l: New test.
* testsuite/gas/riscv/cv-alu-fail-march.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.s: New test.
* testsuite/gas/riscv/cv-alu-insns.d: New test.
* testsuite/gas/riscv/cv-alu-insns.s: New test.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Disassemble xcb operand.
* riscv-opc.c: Defined the MASK and added XCValu instructions.
include/ChangeLog:
* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
for XCValu.
* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
for XCValu.
(enum riscv_insn_class): Added the XCValu instruction class.
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html
Contributors:
Mary Bennett <mary.bennett@embecosm.com>
Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Pietra Ferreira <pietra.ferreira@embecosm.com>
Charlie Keaney
Jessica Mills
Craig Blackmore <craig.blackmore@embecosm.com>
Simon Cook <simon.cook@embecosm.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
Helene Chelin <helene.chelin@embecosm.com>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvmac`
instruction class.
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* config/tc-riscv.c (validate_riscv_insn): Added the necessary
operands for the extension.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Noted XCVmac as an additional ISA extension
for CORE-V.
* testsuite/gas/riscv/cv-mac-fail-march.d: New test.
* testsuite/gas/riscv/cv-mac-fail-march.l: New test.
* testsuite/gas/riscv/cv-mac-fail-march.s: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.d: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.l: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.s: New test.
* testsuite/gas/riscv/cv-mac-insns.d: New test.
* testsuite/gas/riscv/cv-mac-insns.s: New test.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): Disassemble information with
the EXTRACT macro implemented.
* riscv-opc.c: Defined the MASK and added
XCVmac instructions.
include/ChangeLog:
* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
for XCVmac.
* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
for uimm.
(enum riscv_insn_class): Added the XCVmac instruction class.
Just the lightest modifications about this, without any further checks and
considering --emit-relocs. We will need to improve it in the future, but
first do this to avoid conflicts between linker internal relocations and the
new definition of psabi. For example, TLSDESC relocs.
Passed riscv-gnu-toolchain regressions, so should be safe enough to commit.
Co-authored-by: Tsukasa OI <research_trasio@irq.a4lg.com>
bfd/
* reloc.c: Removed linker internal relocations.
* bfd-in2.h: Regenerated.
* libbfd.h: Regenerated.
* elfnn-riscv.c: Defined R_RISCV_DELETE in include/elf/riscv.h.
* elfxx-riscv.c (howto_table, howto_table_internal): Moved linker
internal relocations from howto_table into howto_table_internal.
(riscv_reloc_map): Removed linker internal relocations mapping.
(riscv_elf_rtype_to_howto): Return howto of linker internal
relocations from howto_table_internal.
include/
* elf/riscv.h: Defined linker internal relocations after R_RISCV_max.
We are used to generate these kinds of relocations by data directives.
Considering the following example,
.word (A + 3) - (B + 2)
The GAS will generate a pair of ADD/SUB for this,
R_RISCV_ADD, A + 1
R_RISCV_SUB, 0
The addend of R_RISCV_SUB will always be zero, and the summary of the
constants will be stored in the addend of R_RISCV_ADD/SET. Therefore,
we can always add the addend of these data relocations when doing relocations.
But unfortunately, I had heard that if we are using .reloc to generate
the data relocations will make the relocations failed. Refer to this,
.reloc offset, R_RISCV_ADD32, A + 3
.reloc offset, R_RISCV_SUB32, B + 2
.word 0
Then we can get the relocations as follows,
R_RISCV_ADD, A + 3
R_RISCV_SUB, B + 2
Then... Current LD does the relocation, B - A + 3 + 2, which is wrong
obviously...
So first of all, this patch fixes the wrong relocation behavior of
R_RISCV_SUB* relocations.
Afterwards, considering the uleb128 direcitve, we will get a pair of
SET_ULEB128/SUB_ULEB128 relocations for it for now,
.uleb128 (A + 3) - (B + 2)
R_RISCV_SET_ULEB128, A + 1
R_RISCV_SUB_ULEB128, B + 1
Which looks also wrong obviously, the summary of the constants should only
be stored into the addend of SET_ULEB128, and the addend of SUB_ULEB128 should
be zero like other SUB relocations. But the current LD will still get the right
relocation values since we only add the addend of SUB_ULEB128 by accident...
Anyway, this patch also fixes the behaviors above, to make sure that no matter
using .uleb128 or .reloc directives, we should always get the right values.
bfd/
* elfnn-riscv.c (perform_relocation): Clarify that SUB relocations
should substract the addend, rather than add.
(riscv_elf_relocate_section): Since SET_ULEB128 won't go into
perform_relocation, we should add it's addend here in advance.
gas/
* config/tc-riscv.c (riscv_insert_uleb128_fixes): Set the addend of
SUB_ULEB128 to zero since it should already be added into the addend
of SET_ULEB128.
Extends commit 6136093c0d00 to handle verdefs as well as verrefs.
PR 30886
* elf.c (_bfd_elf_slurp_version_tables): See free_contents for
verdefs too. Use free_contents rather than elf_tdata fields.
Sections without SEC_HAS_CONTENTS avoid the file size checks, and of
course it doesn't make sense to read such as the contents are all
zero.
* som.c (som_set_reloc_info): Don't read sections without contents.
This fixes some holes found by fuzzers, and removes aborts that can be
triggered by user input to objdump. Abort should only be used within
bfd to show programming errors in bfd.
* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Handle
NULL howto. Don't abort on stack errors or on unexpected relocs.
Show more bfd reloc status messages.
The as and ld use _bfd_error_handler to output error messages when
checking relocation alignment and relocation overflow. However, the
abfd value passed by as to the function is NULL, resulting in an
internal error. The ld passes a non-null value to the function,
so it can output an error message normally.
I noticed the regenerated BFD_RELOC_MICROBLAZE_32_NONE comment didn't
match that committed to bfd-in2.h, and was just going to regen
bfd-in2.h but then decided to do something about the silly formatting
of these comments in bfd-in2.h. eg. the BFD_RELOC_MICROBLAZE_32_NONE
comment:
-/* This is a 32 bit reloc that stores the 32 bit pc relative
-value in two words (with an imm instruction).No relocation is
-done here - only used for relaxing */
+ /* This is a 32 bit reloc that stores the 32 bit pc relative value in
+ two words (with an imm instruction). No relocation is done here -
+ only used for relaxing. */
BFD_RELOC_MICROBLAZE_32_NONE,
You'll notice how the second and third line of the original comment
aren't indented properly relative to the first line, and the whole
comment needs to be indented to match the code.
I've also edited reloc.c ENUMDOC paragraphs. Some of these had excess
indentation, presumably in an attempt to properly indent bfd-in2.h
comments but that fails due to chew.c removing leading whitespace
early by skip_white_and_stars. COMMENT was used in reloc.c to add
extra blank lines in bfd-in2.h. I've removed them too as I don't
think they add anything to readability of that file. (Perhaps more
usefully, they also add blank lines to libbfd.h separating relocs for
one target from others, but this isn't done consistently.)
* doc/chew.c (drop, idrop): Move earlier.
(strip_trailing_newlines): Check index before accessing array,
not after.
(wrap_comment): New function.
(main): Add "wrap_comment" intrinsic.
* doc/proto.str (ENUMDOC): Use wrap_comment.
(make_enum_header, ENDSENUM): Put start and end braces on
separate lines.
* reloc.c: Remove uses of COMMENT and edit ENUMDOC paragraphs.
* libbfd.h: Regenerate.
* bfd-in2.h: Regenerate.
This patch adds the R_MICROBLAZE_32_NONE relocation type.
This is a 32-bit reloc that stores the 32-bit pc relative
value in two words (with an imm instruction).
Add test case to gas test suite.
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>
