LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 30406 - "relocation R_X86_64_PC32 cannot refer to absolute symbol ImageBase" (symbol from linker script) error linking FreeBSD/amd64 EFI loader with lld
Summary: "relocation R_X86_64_PC32 cannot refer to absolute symbol ImageBase" (symbol ...
Status: RESOLVED FIXED
Alias: None
Product: lld
Classification: Unclassified
Component: ELF (show other bugs)
Version: unspecified
Hardware: PC FreeBSD
: P normal
Assignee: Unassigned LLVM Bugs
URL:
Keywords:
Depends on:
Blocks: 23214
  Show dependency tree
 
Reported: 2016-09-15 21:58 PDT by emaste
Modified: 2016-10-31 16:37 PDT (History)
6 users (show)

See Also:
Fixed By Commit(s):

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description emaste 2016-09-15 21:58:24 PDT 
Reproduction cpio at https://people.freebsd.org/~emaste/lld/loader.cpio

./ld.lld --trace-symbol=ImageBase $(cat response.txt )
tank/emaste/obj/tank/emaste/src/freebsd-xlld/sys/boot/efi/loader/start.o: reference to ImageBase
(internal): definition of ImageBase
relocation R_X86_64_PC32 cannot refer to absolute symbol ImageBase

ImageBase comes from the linker script:

...
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  . = 0;
  ImageBase = .;
  .hash : { *(.hash) }  /* this MUST come first! */
  . = ALIGN(4096);
  .eh_frame :
  {
...
Comment 1 George Rimar 2016-09-26 06:08:32 PDT 
It is because you use --fatal-warnings,
I prepared a patch: D24908
Comment 2 George Rimar 2016-09-26 06:09:20 PDT 
Sorry posted to wrong bug page.
Comment 3 Petr Hosek 2016-09-26 19:17:28 PDT 
We ran into the same issue so I did the analysis and I believe I found the source of the bug. There are actually several aspects at play here.

Symbols provided by linker scripts are created by DefinedRegular with the input section being null, as a consequence isAbsolute predicate at ELF/Relocations.cpp#283 treats them as absolute symbols and returns an error at ELF/Relocations.cpp#337 which is incorrect.

A possible solution to that issue is to define symbols provided by linker script as synthetic which is possibly a correct thing to do since these don't have an input file or input section anyway.

However, this also uncovered a more general issue: the condition at ELF/Relocations.cpp#335 is very likely incorrect. Symbol can be either undefined or absolute, that fact that this logic convoluted those cases implies that it's wrong. In fact, I tried to link the test case for this logic in ELF/relocation-relative-absolute.s with both BFD ld and gold, and they both handle it just fine emitting a symbol with SHN_ABS section index. The confusion might come from the fact that absolute symbol doesn't necessarily mean non-relocatable symbol here.

Therefore, we should also probably remove this special case which also resolves the error with symbols in the linker script without having to change their type (although we might still want to do that in either case). Also removing that check makes LLD behave the same way as BFD ld and gold.

Do you any opinion/preferences regarding these solutions? I'd be happy to send out a patch once we agree on the solution we want to take here.
Comment 4 Rui Ueyama 2016-10-26 19:15:52 PDT 
Petr,

Sorry for the belated response. I'm not sure if I understand what you said correctly. Probably it is easy to discuss if we have code. Could you sent me (and llvm-commits) a patch so that we can discuss based on that?
Comment 5 Rafael Ávila de Espíndola 2016-10-31 16:37:24 PDT 
Fixed in r285641