HA: [lld] r250584 - [ELF2] - Implemented R_X86_64_PLT32 relocation.

[Hal Finkel via llvm-commits]

----- Original Message -----
> From: "George Rimar" <grimar at accesssoftek.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvm-commits at lists.llvm.org
> Sent: Friday, October 16, 2015 8:42:05 PM
> Subject: HA: [lld] r250584 - [ELF2] - Implemented R_X86_64_PLT32 relocation.
> 
> > От: Hal Finkel [hfinkel at anl.gov]
> > Отправлено: 17 октября 2015 г. 4:39
> > Кому: George Rimar
> > Копия: llvm-commits at lists.llvm.org
> > Тема: Re: [lld] r250584 - [ELF2] - Implemented R_X86_64_PLT32
> > relocation.
> > 
> > Why is the second parameter (NeedsGot) true here? This will cause a
> > .plt entry to be required for undefined weak symbols even when not
> > compiling with -shared.
> > 
> > -Hal
> 
> With false it breaks the test dynamic-reloc-weak.s, where stated
> "Both gold and bfd ld will produce a relocation for sym1 and sym2".
> With false only relocation for sym1 is generated:
> 
>   Section (4) .rela.dyn {
>     0x120A0 R_X86_64_GLOB_DAT sym1 0x0
>   }
> 
> so I decided to keep consistency with ld. I also think it is not an
> issue:
> "A weak undefined reference is like an ordinary undefined reference,
> except that it is not an error if a
>  relocation refers to a weak undefined reference symbol which has no
>  defining symbol. Instead, the relocation is computed as though the
>  symbol had the value zero." (http://www.airs.com/blog/archives/42)

This makes sense. I had been looking at the equivalent issue for PPC64, but had forgotten that the associated behavior is different between those two platforms (see http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151012/305979.html for a demonstration of what I mean).

 -Hal

> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory