[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 --- Comment #10 from Ard Biesheuvel --- (In reply to Renlin Li from comment #9) > (In reply to Peter Smith from comment #5) > > I think that the new error message for R_AARCH64_ABS32 from the linker makes > > some sense if the destination symbol is section relative as there is no > > dynamic relocation supported and truncating a 64-bit address is most likely > > a mistake. > > > > However if the destination symbol is absolute the linker shouldn't make the > > assumption that the symbol is an address so it should resolve the relocation > > at static link-time. > > > > I think the test: > > case BFD_RELOC_AARCH64_16: > > #if ARCH_SIZE == 64 > > case BFD_RELOC_AARCH64_32: > > #endif > > if (bfd_link_pic (info) > > && (sec->flags & SEC_ALLOC) != 0 > > && (sec->flags & SEC_READONLY) != 0) > > ... Give error message > > Should check that the symbol is not absolute as well. > > > > Unfortunately I can't think of a workaround for the case where the value of > > the symbols has to be in the RO-segment. For some reason the check only > > applies in RO sections, which does not make a lot of sense to me as a > > R_AARCH64_ABS32 from a RW section to an address will truncate it in the same > > way as if it were from a RO section. No dynamic relocation is generated for > > either RO or RW so I don't know why the distinction has been made. > > Indeed, for a absolute symbol, the assumption that it represents an address > is not correct. > A check should be added to allow absolute symbol with R_AARCH64_ABS > relocation. > > The condition here is to apply the constrain only in allocatable text or > read-only data section, where I though is more likely to be a place to store > fixed address. > > I will prepare a patch, trying to fix the absolute symbol case. Thank you Renlin. May I kindly suggest that you also look at the other issue, which is related? https://sourceware.org/bugzilla/show_bug.cgi?id=20402 In that case, a runtime relocation is emitted even for SHN_ABS symbols, which means the resulting value becomes dependent on the load address. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 --- Comment #8 from Ard Biesheuvel --- (In reply to Andrew Pinski from comment #7) > (In reply to Matthias Klose from comment #6) > > systemd on aarch64 configured with efi support fails with a similar > > relocation error: > > > > ld -o src/boot/efi/systemd_boot.so -T /usr/lib/elf_aarch64_efi.lds -shared > > -Bsymbolic -nostdlib -znocombreloc -L /usr/lib /usr/lib/crt0-efi-aarch64.o > > --defsym=EFI_SUBSYSTEM=0xa src/boot/efi/disk.c.o src/boot/efi/graphics.c.o > > src/boot/efi/measure.c.o src/boot/efi/pe.c.o src/boot/efi/util.c.o > > src/boot/efi/boot.c.o src/boot/efi/console.c.o src/boot/efi/shim.c.o -lefi > > -lgnuefi /usr/lib/gcc/aarch64-linux-gnu/7/libgcc.a > > ld: /usr/lib/crt0-efi-aarch64.o: relocation R_AARCH64_ABS16 against > > `EFI_SUBSYSTEM' can not be used when making a shared object > > This is a bug in either in gnu-efi or systemd. EFI_SUBSYSTEM is in the > pe-coff header so we don't want any relocation there :). Basically > EFI_SUBSYSTEM is not being defined. Note Uboot has a similar bug too. The PE/COFF header is part of the static GNU=EFI library, and uses a static relocation to populate the efi subsystem field when incorporated into a EFI executable. The ELF spec allows this, so if there is a bug here, it is in ld.bfd not in GNU-EFI, systemd or u-boot. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 --- Comment #4 from Ard Biesheuvel --- (In reply to H.J. Lu from comment #3) > (In reply to Ard Biesheuvel from comment #2) > > > > One could argue that absolute relocations against *absolute* ELF symbols > > should always be resolved at static link time, but I am aware that, for > > historical reasons, symbols like __GLOBAL_OFFSET_TABLE__ are emitted as > > absolute, making this difficult to realise in practice. > > Not true on x86: > > 3987: 003dd000 0 OBJECT LOCAL DEFAULT 33 > _GLOBAL_OFFSET_TABLE_ Oh right. Well, in any case, please refer to this ticket https://sourceware.org/bugzilla/show_bug.cgi?id=20402 and the link in the comments for more discussion on this topic. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 --- Comment #2 from Ard Biesheuvel --- >From commit 79e741920446582bd0e09f3e2b9f899c258efa56 R_AARCH64_ABS64 under LP64 is allowed in shared object and a dynamic relocation entry will be generated. This allows the dynamic linker to do further symbol resolution. R_AARCH64_ABS32 likewise is allowed in shared object, however under ILP32 abi. The original behavior for R_AARCH64_ABS32 under LP64 is that, it's allowed in shared object and silently resolved at static linking time. No dynamic relocation entry is generate for it. One could argue that absolute relocations against *absolute* ELF symbols should always be resolved at static link time, but I am aware that, for historical reasons, symbols like __GLOBAL_OFFSET_TABLE__ are emitted as absolute, making this difficult to realise in practice. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22764] [2.30 Regression] ld fails to link 4.13 and 4.15 kernels on aarch64-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=22764 Ard Biesheuvel changed: What|Removed |Added CC||ard.biesheuvel at linaro dot org --- Comment #1 from Ard Biesheuvel --- The arm64 Linux kernel uses absolute ELF symbols to expose various build time constants whose values are only known after linking to the program itself. The size of the loadable image in little endian format (even on BE builds) The memory footprint of the image in LE The offset to and size of the RELA section, relative to the start of the image (on KASLR kernels) A _kernel_flags_le_hi32 000a A _kernel_flags_le_lo32 A _kernel_offset_le_hi32 0008 A _kernel_offset_le_lo32 A _kernel_size_le_hi32 013b5000 A _kernel_size_le_lo32 004afa00 A __pecoff_data_rawsize 0051d000 A __pecoff_data_size 0200 A PECOFF_FILE_ALIGNMENT 00fa3898 A __rela_offset 002e2ab0 A __rela_size The KASLR kernel is a PIE executable, and is no longer allowed to refer to these symbols via R_AARCH64_ABS32 relocations, resulting in the build error reported by Matthias. So please explain how a PIE executable should refer to such absolute ELF symbols if not via R_AARCH64_ABS32 relocations. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21999] ARM: relative conditional movw/movt pairs may use incorrect offset
https://sourceware.org/bugzilla/show_bug.cgi?id=21999 --- Comment #1 from Ard Biesheuvel --- Thinking about this again, I suppose this is simply a downside of -mimplicit-it, given that putting the label past the 'it' instruction would be inappropriate as well. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/21999] New: ARM: relative conditional movw/movt pairs may use incorrect offset
https://sourceware.org/bugzilla/show_bug.cgi?id=21999 Bug ID: 21999 Summary: ARM: relative conditional movw/movt pairs may use incorrect offset Product: binutils Version: 2.30 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ard.biesheuvel at linaro dot org Target Milestone: --- The following code .syntax unified .thumb movwr0, #:lower16:foo - (1f + 4) movtr0, #:upper16:foo - (1f + 4) 1: add r0, r0, pc movweq r0, #:lower16:foo - (1f + 4) movteq r0, #:upper16:foo - (1f + 4) 1: addeq r0, r0, pc ittteq movweq r0, #:lower16:foo - (1f + 4) movteq r0, #:upper16:foo - (1f + 4) 1: addeq r0, r0, pc assembled for ARMv7 in Thumb2 mode produces the following when using -mimplicit-it=always 0: f64f 70f4 movwr0, #65524 ; 0xfff4 4: f6cf 70f8 movtr0, #65528 ; 0xfff8 8: 4478add r0, pc a: bf04itt eq c: f64f 70f4 movweq r0, #65524 ; 0xfff4 10: f6cf 70f8 movteq r0, #65528 ; 0xfff8 14: bf08it eq 16: 4478addeq r0, pc 18: bf02ittteq 1a: f64f 70f4 movweq r0, #65524 ; 0xfff4 1e: f6cf 70f8 movteq r0, #65528 ; 0xfff8 22: 4478addeq r0, pc Note that the addend is incorrect for the second case: it does not take the additional 'it' instruction in account. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/21183] New: ARM: allow relative symbol references in PC relative ldr literals
https://sourceware.org/bugzilla/show_bug.cgi?id=21183 Bug ID: 21183 Summary: ARM: allow relative symbol references in PC relative ldr literals Product: binutils Version: unspecified Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: ard.biesheuvel at linaro dot org Target Milestone: --- One thing that would be particularly useful in position independent bare metal code that needs to be portable across older ARM versions and even OABI code (such as the Linux kernel) is the ability to emit relative symbol references via ldr. For examples, this code is currently rejected by GAS: ldr \reg, =\sym - (8887f + 8) 8887: ldr \reg, [pc, \reg] but can be open coded in the following way: ldr \reg, f 8887: ldr \reg, [pc, \reg] b 8889f : .long \sym - (8887b + 8) 8889: but this requires an additional branch to jump over the explicit literal. Since this is not a limitation of the ISA, but of the assembler, please consider adding support for this. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20402] ld.bfd for emits *_RELATIVE relocations against SHN_ABS symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=20402 --- Comment #5 from Ard Biesheuvel --- As it turns out, this is a known issue (at least to some): https://sourceware.org/ml/binutils/2012-05/msg00019.html SHN_ABS symbols are treated just like other (section relative) symbols, because symbols like __GLOBAL_OFFSET_TABLE__ and __DYNAMIC are erroneously emitted as absolute. So it seems this cannot be fixed without fixing the underlying problem. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20402] ld.bfd for AArch64 emits R_AARCH64_RELATIVE relocations against SHN_ABS symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=20402 --- Comment #2 from Ard Biesheuvel --- The issue can be reproduced by: abs.s - .quad foo, bar abs.lds --- HIDDEN(foo = ABSOLUTE(0xff00ff11ff22ff33)); bar = ABSOLUTE(0xff44ff55ff66ff77); Build using aarch64-linux-gnu-gcc -pie -nostdlib -o abs -T abs.lds abs.s which produces a binary containing the following relocations Relocation section '.rela.dyn' at offset 0x100c8 contains 2 entries: Offset Info Type Sym. ValueSym. Name + Addend 0403 R_AARCH64_RELATIV-ff00ee00dd00cd 0008 00020101 R_AARCH64_ABS64 ff44ff55ff66ff77 bar + 0 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20402] ld.bfd for AArch64 emits R_AARCH64_RELATIVE relocations against SHN_ABS symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=20402 --- Comment #1 from Ard Biesheuvel --- Uhm, actually it does not fix it. I will try to come up with a small reproducing test case. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/20402] New: ld.bfd for AArch64 emits R_AARCH64_RELATIVE relocations against SHN_ABS symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=20402
Bug ID: 20402
Summary: ld.bfd for AArch64 emits R_AARCH64_RELATIVE
relocations against SHN_ABS symbols
Product: binutils
Version: 2.28 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: ard.biesheuvel at linaro dot org
Target Milestone: ---
ld.bfd in -pie mode will 'optimize' away a R_AARCH64_ABS64 relocation against a
hidden SHN_ABS symbol by replacing it with a R_AARCH64_RELATIVE relocation,
which obviously makes the resulting value in the place dependent on the load
offset rather than fixed.
Instead, I would expect either the relocation to be preserved as a
R_AARCH64_ABS64 relocation to be resolved at load time, or be optimized away
completely, since the symbol is hidden and therefore not preemptible and could
thus be fully resolved at link time.
I don't have a small test case handy (I found this while working on KASLR for
arm64 Linux), but the following hunk fixes the problem completely for me: it
not only prevents the R_AARCH64_RELATIVE relocation from being emitted, but it
fully resolves the relocation and puts the correct 64-bit absolute value in the
place in the ELF binary.
diff --git a/bfd/elfnn-aarch64.c b/bfd/elfnn-aarch64.c
index 3435a3d67339..d1068f56c4ee 100644
--- a/bfd/elfnn-aarch64.c
+++ b/bfd/elfnn-aarch64.c
@@ -5191,7 +5191,8 @@
&& h->dynindx != -1
&& (!bfd_link_pic (info)
|| !SYMBOLIC_BIND (info, h)
- || !h->def_regular))
+ || !h->def_regular
+ || sym->st_shndx == SHN_ABS))
outrel.r_info = ELFNN_R_INFO (h->dynindx, r_type);
else
{
(
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/11539] ld --gc-sections should work for PE-COFF on MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=11539 Ard Biesheuvel changed: What|Removed |Added CC||ard.biesheuvel at linaro dot org --- Comment #18 from Ard Biesheuvel --- I have given this a spin with building the OVMF firmware (EDK2/Tianocore) http://www.tianocore.org/edk2/ In my case, I need to pass -fno-asynchrounous-unwind-tables to actually get some noticeable improvement, since the unwind info seems to hold some live references to code that is otherwise unused. But with that added, it works beautifully. (using GCC 4.9.3 + binutils-gdb 7.10 branch) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18692] AArch64: ld --emit-relocs corrupts section relative relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=18692 --- Comment #2 from Ard Biesheuvel --- Yes, you are right. Sorry for the noise. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/18692] New: AArch64: ld --emit-relocs corrupts section relative relocations
https://sourceware.org/bugzilla/show_bug.cgi?id=18692
Bug ID: 18692
Summary: AArch64: ld --emit-relocs corrupts section relative
relocations
Product: binutils
Version: 2.24
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: ard.biesheuvel at linaro dot org
Target Milestone: ---
When merging ELF sections together, section relative relocations emitted using
--emit-relocs do not have their addends recalculated, leading to corrupt
relocation data.
For instance, after assembling the following code:
.text
.skip 0x20
.quad sym1
.section ".rodata"
sym1:
.skip 0x38
.word 0x0
using "aarch64-linux-gnu-as -o /tmp/rela.o /tmp/rela.s", the resulting
rela.text section contains:
Relocation section '.rela.text' at offset 0x3f0 contains 1 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
0020 00060101 R_AARCH64_ABS64 .rodata + 38
However, after linking it using the following script:
SECTIONS {
.text : { *(.text .rodata) }
}
using "aarch64-linux-gnu-ld -e 0x0 -o /tmp/rela /tmp/rela.o --emit-relocs -T
/tmp/rela.lds", the resulting rela.text section contains the following
relocation:
Relocation section '.rela.text' at offset 0x10298 contains 1 entries:
Offset Info Type Sym. ValueSym. Name +
Addend
0020 00010101 R_AARCH64_ABS64 .text + 38
Here, the RELA addend is unchanged, even though the original .rodata is placed
0x28 bytes into .text.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18541] ARM: adr reference to global symbol fails to assemble in Thumb mode
https://sourceware.org/bugzilla/show_bug.cgi?id=18541 --- Comment #3 from Ard Biesheuvel --- Yes, the patch works fine when applied to 2.24. Thanks. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/18541] New: ARM: adr reference to global symbol fails to assemble in Thumb mode
https://sourceware.org/bugzilla/show_bug.cgi?id=18541 Bug ID: 18541 Summary: ARM: adr reference to global symbol fails to assemble in Thumb mode Product: binutils Version: 2.24 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: ard.biesheuvel at linaro dot org Target Milestone: --- The following ARM code fails to assemble in Thumb mode """ adr r0, cp15_save_power .align .globl cp15_save_power cp15_save_power: .long 0 @ cp15 power control """ $ arm-linux-gnueabihf-as -o /tmp/sleep.o /tmp/sleep.S -mthumb /tmp/sleep.S: Assembler messages: /tmp/sleep.S:1: Error: invalid immediate for address calculation (value = 0x0004) The error goes away when I drop the -mthumb or when I replace the code with """ adr r0, 0f .align .globl cp15_save_power cp15_save_power: 0: .long 0 @ cp15 power control """ -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
