This is an archive of the discontinued LLVM Phabricator instance.

RuntimeDyldELF/AArch64: Implement basic support for PIC relocations
ClosedPublic

Authored by evgeny777 on Jan 11 2017, 10:21 AM.

Details

Summary

This patch does the following:

  • Implements R_AARCH64_ADR_GOT_PAGE and R_AARCH64_LD64_GOT_LO12_NC relocations
  • Fills Global Offset Table with absolute address of target symbol.

Diff Detail

Repository
rL LLVM

Event Timeline

evgeny777 updated this revision to Diff 83998.Jan 11 2017, 10:21 AM
evgeny777 retitled this revision from to RuntimeDyldELF/AArch64: Implement basic support for PIC relocations.
evgeny777 updated this object.
evgeny777 added reviewers: davide, lhames.
evgeny777 set the repository for this revision to rL LLVM.
evgeny777 added subscribers: llvm-commits, grimar.

Any comments on this?

peter.smith edited edge metadata.Jan 18 2017, 3:33 AM

Hello Evgeny,

Just looking at this from a AArch64 perspective. If my understanding is correct it looks like there is at least one case that this would incorrectly resolve the LO12_NC relocation. I've put an example in the comment. I'm not familiar with RuntimeDyld so my comments may not be applicable to the use cases it would be expected to face, I think you'll need to get some comments from the RuntimeDyld code owners for that. I notice the title says basic support, if it is intentionally incomplete it will be worth putting a comment on what hasn't been done yet. The remainder of the patch looks like it is just moving things around so that all looks fine to me.

Peter

lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
1098 ↗(On Diff #83998)

If there is more than one R_AARCH64_ADR_GOT_PAGE relocation to the same symbol S in the object won't this create more than one GOT entry for S?

1111 ↗(On Diff #83998)

Am I correct in thinking that this is assuming that all R_AARCH64_LD64_GOT_LO12_NC to symbol S relocations immediately follow a R_AARCH64_ADR_GOT_PAGE to symbol S?

There isn't anything in the AArch64 ABI that guarantees this and compilers can generate code that doesn't. For example when compiled with the Linaro gcc 5.3.1 20160113 the source file

struct S {
    int a;
    int b;
};
int array[1024];
struct S s;

int func(void)
{
    return s.a + s.b + array[0] + array[1023];
}

produces with aarch64-linux-gnu-gcc -c t.c -fpie -O3
`
Disassembly of section .text:

0000000000000000 <func>:

   0:	90000002 	adrp	x2, 8 <func+0x8>
			0: R_AARCH64_ADR_GOT_PAGE	s
   4:	90000001 	adrp	x1, 1000 <func+0x1000>
			4: R_AARCH64_ADR_GOT_PAGE	array
   8:	f9400042 	ldr	x2, [x2]
			8: R_AARCH64_LD64_GOT_LO12_NC	s
   c:	f9400021 	ldr	x1, [x1]
			c: R_AARCH64_LD64_GOT_LO12_NC	array
  10:	29400043 	ldp	w3, w0, [x2]
  14:	b9400022 	ldr	w2, [x1]
  18:	b94ffc21 	ldr	w1, [x1,#4092]
  1c:	0b000060 	add	w0, w3, w0
  20:	0b020000 	add	w0, w0, w2
  24:	0b010000 	add	w0, w0, w1
  28:	d65f03c0 	ret
  2c:	d503201f 	nop

`
The LO12_NC relocations do not immediately follow GOT_PAGE

I don't know enough about the use cases of dlydelf to know if this is a problem, for example it may only need to link code that is guaranteed to have L012_NC following a GOT_PAGE.

test/ExecutionEngine/RuntimeDyld/AArch64/ELF_ARM64_PIC_relocations.s
2 ↗(On Diff #83998)

I think it will be worth adding a few more tests.

For example the adrp will only produce the R_AARCH64_ADR_GOT_PAGE to _start, you'll need ldr x8, [x8, #:got_lo12:_start] to get R_AARCH64_LD64_GOT_LO12NC.

evgeny777 added inline comments.Jan 18 2017, 7:41 AM
lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp
1111 ↗(On Diff #83998)

Thanks for looking at it. Yes, you're right about the assumption: I expect LO12_NC to immediately follow GOT_PAGE to keep things as simple as possible for the very first patch, otherwise I'd have to implement a mapping between symbol (section) and corresponding GOT entry. I'm using clang and I thought this is not an issue. However, now it looks like such mapping is worth doing.

I don't know enough about the use cases of dlydelf to know if this is a problem, for example it may only need to link code that is guaranteed to have L012_NC following a GOT_PAGE.

I'm using it for run time linking and execution of arbitrary object files, so like you're saying this might be a problem in some cases

evgeny777 updated this revision to Diff 85914.Jan 26 2017, 7:57 AM
evgeny777 added reviewers: eliben, grosbach.

Addressed review comments from Peter:

  • implemented the map between GOT relocation target and corresponding GOT offset
  • added test cases for all supported GOT relocs

I think that those changes address my previous comments, thanks for the update. I've found a couple of what look like typos in the comments. I'm not familiar with rtdyld's organizational and coding conventions so probably best that let an owner take it from here.

test/ExecutionEngine/RuntimeDyld/AArch64/ELF_ARM64_PIC_relocations.s
24 ↗(On Diff #85914)

do you mean "three entries pointing to f, g, and _s"?

Thanks for looking at it. I'll wait a few days in case someone jumps in.

test/ExecutionEngine/RuntimeDyld/AArch64/ELF_ARM64_PIC_relocations.s
24 ↗(On Diff #85914)

Yep. Will fix in final commit

Any comments on this? Davide?

davide edited edge metadata.Jan 31 2017, 7:16 AM

Lang should sign this one off. @lhames

Lang do you have any objections against this? @lhames

eliben removed a reviewer: eliben.Feb 3 2017, 9:49 AM
lhames accepted this revision.Feb 3 2017, 1:42 PM

Looks good to me. :)

This revision is now accepted and ready to land.Feb 3 2017, 1:42 PM
This revision was automatically updated to reflect the committed changes.