[PATCH] D54314: [ELF] - Fix R_AARCH64_ADR_GOT_PAGE, R_AARCH64_LD64_GOT_LO12 handling against IFUNC symbols.

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

Tracing the segfault in the example:

extern "C" int myfunc();

int main() {

  int (*p)() = &myfunc;
  
  return p();

}

  0000000000000000 <main>:
     0:	d10083ff 	sub	sp, sp, #0x20
     4:	a9017bfd 	stp	x29, x30, [sp, #16]
     8:	910043fd 	add	x29, sp, #0x10
     c:	90000008 	adrp	x8, 0 <myfunc>
  			c: R_AARCH64_ADR_PREL_PG_HI21	myfunc
    10:	91000108 	add	x8, x8, #0x0
  			10: R_AARCH64_ADD_ABS_LO12_NC	myfunc
    14:	b81fc3bf 	stur	wzr, [x29, #-4]
    18:	f90003e8 	str	x8, [sp]
    1c:	f94003e8 	ldr	x8, [sp]
    20:	d63f0100 	blr	x8
    24:	a9417bfd 	ldp	x29, x30, [sp, #16]
    28:	910083ff 	add	sp, sp, #0x20
    2c:	d65f03c0 	ret

The R_AARCH64_ADR_PREL_PG_HI21 is represented by R_PAGE_PC. In the segfault we don't generate a PLT entry for the call to myfunc and the blr x8 goes off into the wrong place provoking a crash. On ld.bfd a PLT entry is created and x8 correctly contains the location. Curiously if I turn on optimisation main reduces to a single

  0000000000000000 <main>:
     0:	14000000 	b	0 <myfunc>
  			0: R_AARCH64_JUMP26	myfunc

Which will generate the PLT entry as expected.

To summarise I think we need to handle the R_PAGE_PC expression as well. Although this could be handled in a different patch.


https://reviews.llvm.org/D54314