[llvm-bugs] [Bug 31213] [ELF] - FreeBSD lld linked loader hangs (sys/boot/efi/boot1).

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=31213

George Rimar <grimar at accesssoftek.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #15 from George Rimar <grimar at accesssoftek.com> ---
(In reply to comment #11)
> Something is still not quite right and linking the FreeBSD bootloaders with
> that change does not work for me, although George reported success.

Yes, minimal scenario from this PR as well as building+linking complete source
of usr/src/sys/boot/efi/boot1 loader is fixed for me with
https://reviews.freebsd.org/D8681 applied.

Tested in a next way:
root at freebsd:/usr/src/sys/boot/efi/boot1
make clean
make
objcopy \
  -j .peheader -j .text -j .sdata -j .data  \
  -j .dynamic -j .dynsym -j .rel.dyn  \
  -j .rela.dyn -j .reloc -j .eh_frame \
  --output-target=efi-app-x86_64 boot1.sym.full loader.efi

now loader.efi is workable.

Though I still observe issue with objcopy call from original makefile:
objcopy --only-keep-debug boot1.sym.full boot1.sym.debug
BFD: boot1.sym.debug: section `.dynsym' can't be allocated in segment 4
objcopy: boot1.sym.debug: Bad value
BFD: boot1.sym.debug: section `.dynsym' can't be allocated in segment 4
objcopy: boot1.sym.debug: Bad value
*** Error code 1
That issue can be fixed with passing -N to linker and after that result
boot1.efi also works for me.

(In reply to comment #12)
> Ah, yes. That is an oddity of ld.bfd I had noticed before. If we can fix the
> freebsd code instead of implementing the same oddity in ld.lld that would be
> awesome.
> 

Yep, I also noticed that earlier. I just do not think it is an oddity only of
bfd, I think gold also do that since loader linked from source still has many
left relocations, what means not all of them were relaxed and looks it "worked"
because of the same reasons. (though I did not re-check)
That is why I at first I supposed we might want to do the same, but did not
find anything in ABI or somewhere else about storing addends in relocation
targets.

I am closing this, since this one issue does not requires fixing on LLD side
and we can open separate PR for others if any.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20161201/37b8132a/attachment-0001.html>