Andrew Burgess [Tue, 21 May 2024 14:39:37 +0000 (15:39 +0100)]
gdb: add target_fileio_stat, but no implementations yet
In a later commit I want target_fileio_stat, that is a call that
operates on a filename rather than an open file descriptor as
target_fileio_fstat does.
This commit adds the initial framework for target_fileio_stat, I've
added the top level target function and the virtual target_ops methods
in the target_ops base class.
At this point no actual targets override target_ops::fileio_stat, so
any attempts to call this function will return ENOSYS error code.
Tom de Vries [Wed, 17 Jul 2024 15:04:02 +0000 (17:04 +0200)]
[gdb/testsuite] Fix gdb.arch/arm-pseudo-unwind.exp with unix/mthumb
When running test-case gdb.arch/arm-pseudo-unwind.exp with target board
unix/mthumb, we run into:
...
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGILL, Illegal instruction.^M
0x00400f38 in ?? ()^M
(gdb) FAIL: $exp: continue to breakpoint: continue to callee
...
The test-case attempts to force arm-pseudo-unwind.c to be compiled in arm mode
using additional_flags=-marm, but that's overridden by using target board
unix/mthumb.
This causes function main to be in thumb mode, and consequently function
caller (which is called from main) is is executed as if it's in thumb mode,
while it's actually in arm mode.
Fix this by adding an intermediate function caller_trampoline in
arm-pseudo-unwind.c, and hardcoding it to arm mode using
__attribute__((target("arm"))).
Likewise for test-case gdb.arch/arm-pseudo-unwind-legacy.exp.
Simon Marchi [Thu, 16 May 2024 20:13:20 +0000 (16:13 -0400)]
gdb: make `program_space::free_all_objfiles` use `this`
Use `this` instead of `current_program_space`. Presumably, the method
wants to check the solibs of "this" program space, not the current
global program space (although they are likely always the same at the
moment).
Simon Marchi [Thu, 11 Jul 2024 16:39:35 +0000 (12:39 -0400)]
gdb: pass program space to no_shared_libraries
Make the current program space reference bubble up one level. Pass
`current_program_space` everywhere, except in some cases where we can
get the pspace another way, and it's relatively obvious that it's the
same as the current program space.
Simon Marchi [Thu, 11 Jul 2024 16:38:31 +0000 (12:38 -0400)]
gdb: split no_shared_libraries, command vs implementation
The `no_shared_libraries` function is currently used to implement the
`nosharedlibrary` command, but it also used internally by other
functions. This does not make a very good internal API.
Add the `no_shared_libraries_command` function to implement the CLI
command. Remove the unused parameters from `no_shared_libraries`.
Remove the `from_tty` parameter of `target_pre_inferior`, since it's now
unused.
Simon Marchi [Thu, 16 May 2024 18:04:24 +0000 (14:04 -0400)]
gdb: use objfile::pspace in objfile::unlink
I think it would make sense to use objfile::pspace instead of the
current program space here. It reduces the risks of calling this
method with the wrong current program space set.
Simon Marchi [Mon, 15 Jul 2024 15:02:15 +0000 (15:02 +0000)]
gdb: remove some trivial uses of current_program_space
It is obvious that pspace is the same as current_program_space in these
cases, due to the set_current_program_space call just above. The rest
of the functions probably care about the current program space though,
so leave the set_cset_current_program_space calls there.
Hannes Domani [Mon, 15 Jul 2024 14:29:36 +0000 (16:29 +0200)]
Fix loading a saved recording
Currently you get this assertion failure if you try to execute the
inferior after loading a saved recording, when no recording was done
earlier in the same gdb session:
```
$ gdb -q c -ex "record restore test.rec"
Reading symbols from c...
[New LWP 26428]
Core was generated by `/tmp/c'.
Restored records from core file /tmp/test.rec.
(gdb) c
Continuing.
../../gdb/inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
```
The change in step-precsave.exp triggers this bug, since now the
recording is loaded in a new gdb session, where
record_full_resume_ptid was never set.
The fix is to simply set record_full_resume_ptid when resuming a loaded
recording.
hppa: Fix handling of relocations that apply to data
Commit d125f9675372b1ae01ceb1893c06ccb27bc7bf22 introduced a bug
in handling relocations for data. The R_PARISC_DIR32 relocation
operates on 32-bit data and not instructions. The HOWTO table
needs to be used to determine the format of relocations that apply
to data. The R_PARISC_SEGBASE relocation is another special case
as it only changes segment base.
This was noticed in Debian cmor package build.
2024-07-14 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf32-hppa.c (final_link_relocate): Use HOWTO table to
determine reload format for relocations that apply to data.
Lulu Cai [Thu, 11 Jul 2024 11:00:43 +0000 (19:00 +0800)]
LoongArch: Fix dwarf3 test cases from XPASS to PASS
In the past, the .align directive generated a label that did not match
the regular expression, and we set it to XFAIL.
But now it matches fine so it becomes XPASS. We fix it with PASS.
Sam James [Sat, 29 Jun 2024 17:11:52 +0000 (18:11 +0100)]
libiberty: sync with gcc
This imports the following commits from GCC as of r15-1722-g7682d115402743: ca2f7c84927f libiberty: Invoke D demangler when --format=auto 94792057ad4a Fix up duplicated words mostly in comments, part 1 20e57660e64e libiberty: Fix error return value in pex_unix_exec_child [PR113957]. 52ac4c6be866 [libiberty] remove TBAA violation in iterative_hash, improve code-gen 53bb7145135c libiberty: Fix up libiberty_vprintf_buffer_size 65388b28656d c++, demangle: Implement https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal
s390: Avoid reloc overflows on undefined weak symbols (cont)
This complements and reuses logic from Andreas Krebbel's commit 896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols").
Replace relative long addressing instructions of weak symbols, which
will definitely resolve to zero, with either a load address of 0 or a
a trapping insn.
This prevents the PLT32DBL relocation from overflowing in case the
binary will be loaded at 4GB or more.
bfd/
* elf64-s390.c (elf_s390_relocate_section): Replace
instructions using undefined weak symbols with relative
addressing to avoid relocation overflows.
ld/
* testsuite/ld-s390/s390.exp: Add new test.
* testsuite/ld-s390/weakundef-2.s: New test.
* testsuite/ld-s390/weakundef-2.dd: Likewise.
Reported-by: Alexander Gordeev <agordeev@linux.ibm.com> Suggested-by: Ilya Leoshkevich <iii@linux.ibm.com> Suggested-by: Andreas Krebbel <krebbel@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
s390: Do not replace brcth referencing undefined weak symbol
Branch Relative on Count High (brcth) is a conditional branch relative
instruction. It is not guaranteed that it only appears within loops
that sooner or later will take the branch. It may very well be used to
check a condition that will prevent the branch from ever being taken.
bfd/
* elf64-s390.c (elf_s390_relocate_section): Do not replace brcth
referencing undefined weak symbol with a trap.
ld/
* testsuite/ld-s390/weakundef-1.s: Update test case accordingly.
* testsuite/ld-s390/weakundef-1.dd: Likewise.
aarch64: Add support for sme2.1 zero instructions.
This patch adds support for following sme2.1 zero instructions and
the spec is available here [1].
1. ZERO (single-vector).
2. ZERO (double-vector).
3. ZERO (quad-vector).
The VECTOR GROUP symbols VGx2 and VGx4 are optional for the assembler
for most of the sme and sve instructions. But for few of the sme2.1
zero instruction variants VECTOR GROUP symbols VGx2 and VGx4 are mandatory.
To address this a bit "F_VG_REQ" is introduced in this patch, on setting
F_VG_REQ bit in flags of aarch64_opcode forces the assembler to accept
instruction operand only having VECTOR GROUP symbols.
Jan Beulich [Fri, 12 Jul 2024 10:28:50 +0000 (12:28 +0200)]
x86: drop unnecessary \() from bundle tests
':' isn't permitted in macro parameter names, hence this separator
construct isn't necessary at the end of labels. Drop its use in such
cases, for being potentially confusing (and hampering readability, even
if only a little).
Jan Beulich [Fri, 12 Jul 2024 10:28:03 +0000 (12:28 +0200)]
x86/APX: remove two inconsistencies
As indicated in earlier discussion, permitting GOTTPOFF uniformly for
all legacy non-SIMD insns while at the same time restricting to just
certain ADD forms when EVEX-encoded is inconsistent. Make promoted insns
"equal" to their legacy original ones. Doing that adjustment prevents
another inconsistency, too: In
it is not logical why the last one shouldn't be permitted. Bypassing
that check requires other adjustments, though, to actually properly
consume (and then squash) the data size prefix.
While there also add the missing CMP and TEST cases to the test case
being modified.
Jan Beulich [Fri, 12 Jul 2024 10:27:19 +0000 (12:27 +0200)]
x86/APX: correct TEST/CTESTcc with 1st operand being a memory one
While they properly inherited D and C, code processing the reversal of
operands wasn't updated accordingly (and "reversed" operands also
weren't tested anywhere).
YunQiang Su [Wed, 19 Jun 2024 16:52:25 +0000 (00:52 +0800)]
MIPS/GAS: Omit LI 0 for condition trap
MIPSr6 removes condition trap instructions with imm, so we expand
the instruction like "tne $2,IMM" to
li $at,IMM
tne $2,$at
While if IMM is 0, we can use
tne $2,$zero
only.
Alan Modra [Fri, 12 Jul 2024 00:20:46 +0000 (09:50 +0930)]
Re: base64: Add support for targets with byte size > octet size.
Three extra octets are now expected with the latest change to base64.s.
They happened to be covered by patterns allowing for zero padding at
the end of the section, but we don't want to allow fewer octets than
expected.
Jan Beulich [Thu, 11 Jul 2024 10:26:36 +0000 (12:26 +0200)]
gas: multi-byte warning adjustments
First input_scrub_next_buffer()'s invocation was wrong, leading to input
only being checked from the last newline till the end of the current
buffer. Correcting the invocation, however, leads to duplicate checking
unless -f (or the #NO_APP equivalent thereof) is in effect. Move the
invocation to input_file_give_next_buffer(), to restrict it accordingly.
Then, when macros contain multi-byte characters, warning about them
again in every expansion isn't useful. Suppress such warnings from
sb_scrub_and_add_sb().
Jan Beulich [Thu, 11 Jul 2024 10:25:26 +0000 (12:25 +0200)]
gas: there's no scrubber state 12
Apparently (beyond what's [easily] visible in git history) when this was
added there was confusion about scrubber states vs lex[] contents. For
the purposes here LEX_IS_DOUBLEDASH_1ST (which happens to also resolve
to 12) alone is sufficient. "state" is never set to 12, and it being 12
also isn't handled anywhere.
More of a DWARF-generation non-regression test; fixed on the GCC side
with 2024-06-03 "Implement wrap-around arithmetics in DWARF
expressions" (f3d6d60d2ae).
RISC-V Profiles document defines number of "extensions" that indicate
certain platform properties/capabilities just like 'Zkt' extension from the
RISC-V cryptography extensions.
This commit defines 20 platform property/capability extensions as defined
in the RISC-V Profiles documentation.
The only exception: 'Ssstateen' extension is defined separately because it
defines a subset (supervisor/hypervisor view) of the 'Smstateen' extension.
This is based on the ratified version of RISC-V Profiles:
<https://github.com/riscv/riscv-profiles/releases/tag/v1.0>
[Definition]
"Main memory regions":
Main memory regions (in contrast to I/O or vacant memory regions) with
both the cacheability and coherence PMAs.
[New Unprivileged Extensions]
1. 'Ziccif'
"Main memory regions" support instruction fetch and any instruction
fetches of naturally aligned power-of-2 sizes up to min(ILEN, XLEN)
are atomic.
2. 'Ziccrse'
"Main memory regions" provide the eventual success guarantee for
LR/SC sequence (RsrvEventual).
3. 'Ziccamoa'
"Main memory regions" support all currently-defined AMO operations
including swap, logical and arithmetic operations (AMOArithmetic).
4. 'Za64rs'
For LR/SC instructions, reservation sets are contiguous, naturally
aligned and at most 64-bytes in size.
5. 'Za128rs'
Likewise, but reservation sets are at most 128-bytes in size.
6. 'Zicclsm'
Misaligned loads / stores to "main memory regions" are supported.
Those include both regular scalar and vector accesses but does not
include AMOs and other specialized forms of memory accesses.
7. 'Zic64b'
Cache blocks are (exactly) 64-bytes in size and naturally aligned.
[New Privileged Extensions]
1. 'Svbare'
"satp" mode Bare is supported.
2. 'Svade'
Page-fault exceptions are raised when a page is accessed when A bit is
clear, or written when D bit is clear.
3. 'Ssccptr'
"Main memory regions" support hardware page-table reads.
4. 'Sstvecd'
"stvec" mode Direct is supported. When "stvec" mode is Direct,
"stvec.BASE" is capable of holding any valid 4-byte aligned address.
5. 'Sstvala'
"stval" is always written with a nonzero value whenever possible as
specified in the Privileged Architecture documentation
(version 20211203: see section 4.1.9).
6. 'Sscounterenw'
For any "hpmcounter" that is not read-only zero, the corresponding bit
in "scounteren" is writable.
7. 'Ssu64xl'
"sstatus.UXL" is capable of holding the value 0b10
(UXLEN==64 is supported).
8. 'Shcounterenw'
Similar to 'Sscounterenw' but the same rule applies to "hcounteren".
9. 'Shvstvala'
Similar to 'Sstvala' but the same rule applies to "vstval".
10. 'Shtvala'
"htval" is written with the faulting guest physical address as long as
permitted by the ISA (a bit similar to 'Sstvala' and 'Shvstvala').
11. 'Shvstvecd'
Similar to 'Sstvecd' but the same rule applies to "vstvec".
12. 'Shvsatpa'
All translation modes supported in "satp" are also supported in "vsatp".
13. 'Shgatpa'
For each supported virtual memory scheme SvNN supported in "satp", the
corresponding "hgatp" SvNNx4 mode is supported. The "hgatp" mode Bare
is also supported.
[Implications]
(Due to reservation set size constraints)
- 'Za64rs' -> 'Za128rs'
(Due to the fact that a privileged "extension" directly refers a CSR)
- 'Svbare' -> 'Zicsr'
- 'Sstvecd' -> 'Zicsr'
- 'Sstvala' -> 'Zicsr'
- 'Sscounterenw' -> 'Zicsr'
- 'Ssu64xl' -> 'Zicsr'
(Due to the fact that a privileged "extension" indirectly depends on CSRs)
- 'Svade' -> 'Zicsr'
(Due to the fact that a privileged "extension" is a hypervisor property)
- 'Shcounterenw' -> 'H'
- 'Shvstvala' -> 'H'
- 'Shtvala' -> 'H'
- 'Shvstvecd' -> 'H'
- 'Shvsatpa' -> 'H'
- 'Shgatpa' -> 'H'
bfd/
* elfxx-riscv.c (riscv_implicit_subsets): Updated for property
and capability extensions.
(riscv_supported_std_z_ext): Added zic64b, ziccamoa, ziccif, zicclsm,
ziccrse, za64rs and za128rs extensions.
(riscv_supported_std_s_ext): Added shcounterenw, shgatpa, shtvala,
shvsatpa, shvstvala, shvstvecd, ssccptr, sscounterenw, sstvala,
sstvecd, ssu64xlm svade and svbare extensions.
gas/
* testsuite/gas/riscv/imply.d: Updated for property and capability
extensions.
* testsuite/gas/riscv/imply.s: Likewise.
* testsuite/gas/riscv/march-help.l: Likewse.
Alan Modra [Thu, 11 Jul 2024 01:38:50 +0000 (11:08 +0930)]
Re: Add support for a .base64 pseudo-op to gas
Fixes a failure on rx-elf where the standard data section isn't .data.
run_dump_test has machinery to translate .data in both options and
expected results for objdump, but not for readelf -x.
PR 31964
* testsuite/gas/all/base64.d: Dump .data with objdump. Run on
all targets.
Libsframe was missing AC_CANONICAL_TARGET, meaning that --target was
ignored. This could prevent libsframe.a to be installed in some cases,
the host fetching its canonical value while the target isn't. Both
having a different value, INSTALL_LIBBFD would be false.
H.J. Lu [Tue, 9 Jul 2024 08:48:54 +0000 (01:48 -0700)]
elf: Add glibc version dependency only if needed
There is no need to add a needed glibc version if the glibc base version
includes the needed glibc version.
PR ld/31966
* elflink.c (elf_link_add_glibc_verneed): Add glibc_minor_base.
Skip if the glibc base version includes the needed glibc version.
(_bfd_elf_link_add_glibc_version_dependency): Initialize
glibc_minor_base to INT_MAX and pass it to
elf_link_add_glibc_verneed.
gprofng: add hardware counters for Intel Ice Lake processor
gprofng/ChangeLog
2024-07-07 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
* common/hwc_cpus.h: New constant for Intel Ice Lake processor.
* common/hwcdrv.c: Add a new argument to hwcfuncs_get_x86_eventsel.
Set config1 in perf_event_attr. Remove the use of memset.
* common/core_pcbe.c (core_pcbe_get_eventnum): Return 0.
* common/hwcentry.h: Add config1.
* src/collctrl.cc (Coll_Ctrl::build_data_desc):Set config1.
* common/hwcfuncs.c (process_data_descriptor): Set config1.
* common/hwctable.c: Add the hwc table for Intel Ice Lake processor.
* src/hwc_intel_icelake.h: New file.
Indu Bhagat [Wed, 26 Jun 2024 19:43:51 +0000 (12:43 -0700)]
doc: sframe: add appendix for generating stack traces
Add an appendix to provide a rough outline to show how to generate stack
traces using the SFrame format. Such content should hopefully aid the
reader assimmilate the information in the specification.
libsframe/
* doc/sframe-spec.texi: Add new appendix.
include: sframe: update code comments around SFrame FRE stack offsets
This also amends the incorrect comment:
offset3 (intrepreted as FP = CFA + offset2)
If RA tracking is enabled, the offset to recover FP is at the third
index. The SFrame format (V2) has assumption that if FP is saved on
stack, RA must have been saved as well. This is true for the currently
supported arch Aarch64. For AMD64, RA tracking per SFrame FRE is not
necessary.
In future, when extending support for more architectures, this will
likely need to be revisited.
include/
* sframe.h: Make the comments clearer by enumerating what
happens per-ABI.
Indu Bhagat [Thu, 23 May 2024 21:18:23 +0000 (14:18 -0700)]
doc: sframe: segregate the ABI/arch-specific components
The recipe to interpret the SFrame FRE stack offsets is
ABI/arch-specific.
Although, there is other information in the specification that is
ABI-specific (like pauth_key usage in AArch64), those pieces of
information are now assimmilated in the SFrame specification in a way
that it is fairly difficult to carve then out into a ABI/arch-specific
section without confusing the readers.
For future though, the specification must strive to keep the generic
parts and ABI/arch-specific parts clearly laid out in separate sections.
libsframe/
* doc/sframe-spec.texi: Reorder and adapt the contents.
H.J. Lu [Tue, 9 Jul 2024 08:30:19 +0000 (01:30 -0700)]
LTO: Properly check wrapper symbol
Add wrapper_symbol to bfd_link_hash_entry and set it to true for wrapper
symbol. Set wrap_status to wrapper if wrapper_symbol is true in LTO.
Note: Calling unwrap_hash_lookup to check for the wrapper symbol works
only when there is a definition for the wrapped symbol since references
to the wrapped symbol have been redirected to the wrapper symbol.
bfd/
PR ld/31956
* linker.c (bfd_wrapped_link_hash_lookup): Set wrapper_symbol
for wrapper symbol.
PR ld/31956
* plugin.c (get_symbols): Set wrap_status to wrapper if
wrapper_symbol is set.
* testsuite/ld-plugin/lto.exp: Run PR ld/31956 tests.
* testsuite/ld-plugin/pr31956a.c: New file.
* testsuite/ld-plugin/pr31956b.c: Likewise.
This patch adds support for followign SVE2p1 instruction, spec is available here [1].
1. PMOV (to vector)
2. PMOV (to predicate)
Both pmov (to vector) and pmov (to predicate) have destination scalable vector
register and source scalable vector register respectively as an operand with no
suffix and optional index. To handle this case we have added 8 new operands in
this patch.
This patch adds support for SVE2p1 "tbxq" instruction, spec is available here [1].
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en
aarch64: Add support for sve2p1 zipq[1-2] instructions.
This patch adds support for SVE2p1 "zipq1" and "zipq2" instructions, spec is
available here [1].
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en
aarch64: Add support for sve2p1 uzpq[1-2] instructions.
This patch adds support for SVE2p1 "uzpq1" and "uzpq2" instructions, spec is
available here [1]
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en
This patch adds support for SVE2p1 "tblq" instruction, spec is available here [1].
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en
This patch adds support for SVE2p1 "orqv" instruction, spec available here [1].
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en
Alan Modra [Fri, 5 Jul 2024 13:11:49 +0000 (22:41 +0930)]
objcopy bfd_map_over_sections and global status
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.
Jan Beulich [Fri, 5 Jul 2024 06:39:28 +0000 (08:39 +0200)]
RISC-V: avoid use of match_opcode() in riscv_insn_types[]
As of 27b33966b18e ("RISC-V: disallow x0 with certain macro-insns") the
.match_func field may be NULL for entries used for assembly only, which
is the case for the entire table. With .match and .mask both zero the
function would only ever succeed anyway. Save almost a hundred base
relocations in the final executable by using NULL instead.
Xi Ruoyao [Sun, 30 Jun 2024 07:18:25 +0000 (15:18 +0800)]
LoongArch: Add DT_RELR tests
Most tests are ported from AArch64.
The relr-addend test is added to make sure the addend (link-time address)
is correctly written into the relocated section. Doing so is not
strictly needed for RELA, but strictly needed for RELR).
Xi Ruoyao [Sun, 30 Jun 2024 07:18:24 +0000 (15:18 +0800)]
LoongArch: Add DT_RELR support
The logic is same as a71d87680110 ("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.
Xi Ruoyao [Sun, 30 Jun 2024 07:18:23 +0000 (15:18 +0800)]
LoongArch: Make protected function symbols local for -shared
On LoongArch there is no reason to treat STV_PROTECTED STT_FUNC symbols
as preemptible. See the comment above LARCH_REF_LOCAL for detailed
explanation.
"ld -shared" produces a shared object with one R_LARCH_NONE (instead of
R_LARCH_JUMP_SLOT as we expect) to relocate the GOT entry of "ifunc".
It's because the indices in .plt and .rela.plt mismatches for
STV_DEFAULT STT_IFUNC symbols when another PLT entry exists for a
STV_HIDDEN STT_IFUNC symbol, and such a mismatch breaks the logic of
loongarch_elf_finish_dynamic_symbol. Fix the issue by reordering .plt
so the indices no longer mismatch.
DYNAMIC RELOCATION RECORDS
OFFSET TYPE VALUE 00000000000001a8 R_LARCH_RELATIVE *ABS*+0x00000000000001a8
But this is just wrong: at runtime the dynamic linker will run
*(uintptr *)&x += load_address, clobbering the next 4 bytes of data
("0xdeadbeef" in the example).
If we keep the R_LARCH_32 reloc as-is in ELFCLASS64, it'll be rejected
by the Glibc dynamic linker anyway. And it does not make too much sense
to modify Glibc to support it. So we can just reject it like x86_64:
relocation R_X86_64_32 against `.data' can not be used when making a
shared object; recompile with -fPIC
or RISC-V:
relocation R_RISCV_32 against non-absolute symbol `a local symbol'
can not be used in RV64 when making a shared object
projects / thirdparty / binutils-gdb.git / log
