[llvm] r323297 - Don't assume a null GV is local for ELF and MachO.

Rafael Avila de Espindola via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 13 14:28:37 PST 2018


On a related note, the gnu assembler was recently change to produce a
R_X86_64_PLT32 for "call foo". See
https://bugs.llvm.org/show_bug.cgi?id=36370 for the details.

And no, you really don't need to implement logic for creating a GOT in
grub, unless grub has a dynamic linker with support for shared libraries
:-)

Cheers,
Rafael

Brooks Moses <bmoses at google.com> writes:

> On Fri, Feb 9, 2018 at 11:10 AM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
>
>> Brooks Moses <bmoses at google.com> writes:
>> > On Fri, Feb 9, 2018 at 6:54 AM, Rafael Avila de Espindola <
>> > rafael.espindola at gmail.com> wrote:
>> >> Any news? I would really like to recommit the patch.
>> >>
>> >> It seems unreasonable to hold back a llvm patch because another software
>> >> has an incomplete linker implementation, specially when a patch is
>> >> available.
>> >
>> > Sorry for the delay -- my colleague reports that he's testing this now.
>> (I
>> > think he was out yesterday.)
>>
>
> Update: We've tested this on several machines and it appears to be working.
>
> However, one of my Grub-developer coworkers is concerned that this may not
> be the right approach.  I personally think you're right, but I'm not
> anywhere near an expert, so I've filed a bug against the Grub project
> explaining the issue, so that you and my coworker and the other upstream
> Grub people can all get on the same page (whatever page that is) about how
> this should work.  The bug is here:
> https://savannah.gnu.org/bugs/index.php?53113
>
> If possible, I'd like to wait on re-committing this until we know this
> approach is something the Grub developers are happy with (regardless of
> when/where/which patch lands), so that we have a path forward that we know
> won't get broken by Grub going a different direction.
>
>
>> > Do you have a reference for the part of the ELF ABI that describes why
>> the
>> > PLT32 references should be treated as PC32 references here?
>>
>> It comes from the definition of the plt in the PSABI:
>>
>> https://github.com/hjl-tools/x86-psABI/wiki/intel386-psABI-1.1.pdf
>>
>> Since the final function is know, calling the plt is the same is calling
>> the final function.
>>
>
> Thanks!  I've passed that along in hopes of convincing my coworker that
> this doesn't require a full GOT implementation in Grub.  :)
>
> - Brooks


More information about the llvm-commits mailing list