People, including me, had forgotten that the bfd_error_handler just
handled standard printf format strings, not MSC %I64 and suchlike.
Using PRIx64 and similar in errors does not work if the host compiler
headers define those formats as the Microsoft %I64 variety. (We
handled %ll OK, editing it to %I64 on such hosts.)
PR 32507
* bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Handle %I64 and %I32
in input strings if the host defines PRId64 as "I64d".
Edit %ll to %I64 on detecting PRId64 as "I64d" rather than on
a preprocessor define.
(cherry picked from commit b38cf91f23)
For PDE, "recompiling with -fPIE" just makes no sense.
For PIE, "recompiling with -fPIE" makes sense for unresolvable absolute
relocs, but not unresolveable PC-relative relocs: if the reloc is
already PC-relative, the problem is not the reloc is PC-relative or
absolute, but the reloc is not applicable for external symbols.
If we hit an unresolvable reloc in PDE or an unresolvable PC-relative
reloc in PIE, it means the programmer has somehow wrongly instructed the
compiler to treat external symbols as local symbols. A misuse of
-mdirect-extern-access can cause the issue, so we can suggest
-mno-direct-extern-access. And in all cases (DSO/PIE/PDE) a mismatching
symbol visibility can also cause the issue, so we should also suggest to
check the visibility.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
In a static PIE, undefined weak symbols should be just resolved to
runtime address 0, like those symbols with non-default visibility. This
was silently broken in all prior Binutils releases with "-static-pie
-mdirect-extern-access":
$ cat t.c
int x (void) __attribute__ ((weak));
int
main (void)
{
__builtin_printf("%p\n", x);
}
$ gcc t.c -static-pie -mdirect-extern-access
$ ./a.out
0x7ffff1d64000
Since commit 4cb77761d6 ("LoongArch: Check PC-relative relocations for
shared libraries), the situation has been improved: the linker errors
out instead of silently producing a wrong output file.
But logically, using -mdirect-extern-access for a static PIE perfectly
makes sense, and we should not prevent that even if the programmer uses
weak symbols. Linux kernel is such an example, and Linux < 6.10 now
fails to build with Binutils trunk. (The silent breakage with prior
Binutils releases was "benign" due to some blind luck.)
While since the 6.10 release Linux has removed those potentially
undefined weak symbols (due to performance issue), we still should
support weak symbols in -mdirect-extern-access -static-pie and unbreak
building old kernels.
Link: https://lore.kernel.org/loongarch/20241206085810.112341-1-chenhuacai@loongson.cn/
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
An undefined weak hidden/protect symbol should be resolved to runtime
address 0, but we were actually resolving it to link-time address 0. So
in PIE or DSO the runtime address would be incorrect.
Fix the issue by rewriting pcalau12i to lu12i.w, and pcaddi to addi.w.
The latter does not always work because the immediate field of addi.w is
narrower, report an error in the case the addend is too large.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
This patch corrects layout for a PT_LOAD header that doesn't include
the ELF file header but does contain PHDRs and sections requiring
alignment. The required alignment (which was missing) is placed
before the PHDRs.
The fix for PR binutils/31872 (commit b20ab53f81) neglected the case
of targets with only RELA support, where nevertheless object files using
REL exist. In particular objcopy will create such objects for x86-64
when converting from an i?86 ELF object (this by itself probably isn't
quite right, but we ought to cope with what our own tools are doing).
Restore the fallback to the RELA lookup, just without re-introducing the
blind NULL de-ref that was there before.
Both of these targets extend elf_link_hash_entry, so arguably should
set hash_table_id to something other than GENERIC_ELF_DATA. The patch
also sorts enum elf_target_id.
aarch64, am33, csky, ia64-vms, kvx, and sparc64 all use more than
the base GENERIC_ELF_DATA, but don't set ELF_TARGET_ID. Fix that.
These are all targets that use other than GENERIC_ELF_DATA in their
object and hash table ids.
* elf32-am33lin.c,
* elf32-csky.c,
* elf64-ia64-vms.c,
* elf64-sparc.c,
* elfnn-aarch64.c,
* elfnn-kvx.c (ELF_TARGET_ID): Define.
These targets currently use GENERIC_ELF_DATA as their target_id, but
that isn't exactly correct. While their bfd tdata is generic elf,
their elf_section_data is extended with extra target data. Add
MMIX_ELF_DATA and SCORE_ELF_DATA.
Nowhere in the aarch64 backend is the list created by this function
examined, and in any case there are much simpler ways to determine the
type of elf_section_data attached to a bfd ELF section. It will
always be according to the target_id of the section owner.
Delete sections_with_aarch64_elf_section_data and everything
associated with it.
