aaelf32 and aaelf64 missing information required by generic ELF about abi-aa

[smithp35]

Documenting this would be more natural in the sysvabi as that has a dedicated section on the ToDo list on Program Loading and Dynamic Linking (#152).

The reserved contents of The GOT for example are a convention between the dynamic loader and static linker.

Whether the .got or .got.plt are in separate sections is to some degree convention. In AArch32 the GNU ld default linker script merges the two:
.got : { *(.got.plt) *(.igot.plt) *(.got) *(.igot) }
but on AArch64 it keeps them separate as the .got can be made RELRO but the .got.plt cannot (with lazy binding)
.got : { *(.got) *(.igot) }
. = DATA_SEGMENT_RELRO_END (24, .);
.got.plt : { *(.got.plt) *(.igot.plt) }

It isn't compulsary to have a single .got in AArch32, lld keeps the .got and .got.plt separate in its default layout. I think the important part to document is the value of the _GLOBAL_OFFSET_TABLE_ symbol which the compiler sometimes refers to by convention as meaning base of the GOT, it is important to know whether that is the base of the .got or .got.plt.

[MaskRay]

Defining _GLOBAL_OFFSET_TABLE_ (the start of .got) will be nice. On x86, the lack of clarity caused https://reviews.llvm.org/D59594 to lld.

Note that we should not require .got[0] == _DYNAMIC. GNU ld's aarch64 port reserves the entry for glibc rtld but ld.lld does not reserve the entry. I have removed glibc 2.35's reliance on _GLOBAL_OFFSET_TABLE_[0] for arm/aarch64.

[rearnsha]

Why does it need to be defined? It's just a hook for the linker to calculate offsets against. Indeed, on AArch32 there's the potential to put the GLOBAL_OFFSET_TABLE in the middle of the GOT and then you can use negative offsets as well as positive ones to double the useful size of the GOT with instructions like LDR.

[smithp35]

From memory it is because there are some code-sequences where it can matter. For example GCC will generate for -fpic

// aarch64-linux-gnu -c -fpic file.c
// int foo;
// int func() { return foo; }
       0: 00 00 00 90   adrp    x0, 0x0 <func>
                0000000000000000:  R_AARCH64_ADR_PREL_PG_HI21   _GLOBAL_OFFSET_TABLE_
       4: 00 00 40 f9   ldr     x0, [x0]
                0000000000000004:  R_AARCH64_LD64_GOTPAGE_LO15  foo
       8: 00 00 40 b9   ldr     w0, [x0]
       c: c0 03 5f d6   ret

The ldr x0, [x0] // R_AARCH64_LD64_GOTPAGE_LO15 foo is unsigned so GLOBAL_OFFSET_TABLE can't be above the GOT.

[mmalcomson]

W.r.t. the part of the issue around the gABI referencing section names in the processor supplement (which don't match our section names).
I've got the impression from this thread that we're not concerned about that, is that correct?

W.r.t. the fact that we do not describe what is stored in DT_PLTGOT in any of our documents.
That seems like something we should address if it's not specified in any generic ABI specification.
The description of "an address associated with the procedure linkage table and/or the global offset table" which is what the generic ABI uses doesn't seem sufficient.
I think we should add mention of it in the sysvabi -- does that sound right?

[smithp35]

I agree that the sysvabi is the right place for a description of DT_PLTGOT. I can send a patch for that later this week.

On Arm and AArch64 it is just the address of the .got.plt section. This is the case for most architectures I think. Looking at the linker code there are some differences on some targets, such as with Sparc where it is expected to point at the start of the .plt section. This difference for some processors probably prevented the gABI from defining it.

[smithp35]

#173 created to add definition of DT_PLTGOT to sysvabi64

[smithp35]

#173 has been merged and does contain a definition of DT_PLTGOT. I'm closing this issue for now. If there's anything we've missed we can reopen or raise a new issue.