[lld] r295632 - Add more comments about copy relocations.

[Rui Ueyama via llvm-commits]

Are you suggesting I bring it up to the LLVM blog? This comment is my
opinion, and I guess not everybody agrees we should avoid exporting globals
from DSOs.

On Mon, Feb 20, 2017 at 7:49 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> Hi Rui,
>
> I certainly found this informative, thanks for writing this. I think this
> would also be a good topic for a blog post; those will get a larger
> audience.
>
>  -Hal
>
>
>
> On 02/19/2017 08:22 PM, Rui Ueyama via llvm-commits wrote:
>
>> Author: ruiu
>> Date: Sun Feb 19 20:22:56 2017
>> New Revision: 295632
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=295632&view=rev
>> Log:
>> Add more comments about copy relocations.
>>
>> Modified:
>>      lld/trunk/ELF/Relocations.cpp
>>
>> Modified: lld/trunk/ELF/Relocations.cpp
>> URL: http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/Relocation
>> s.cpp?rev=295632&r1=295631&r2=295632&view=diff
>> ============================================================
>> ==================
>> --- lld/trunk/ELF/Relocations.cpp (original)
>> +++ lld/trunk/ELF/Relocations.cpp Sun Feb 19 20:22:56 2017
>> @@ -461,6 +461,21 @@ static std::vector<SharedSymbol<ELFT> *>
>>   // dynamic linker, and the relocation contains not only symbol name but
>>   // various other informtion about the symbol. So, such attributes
>> become a
>>   // part of the ABI.
>> +//
>> +// Note for application developers: I can give you a piece of advice if
>> +// you are writing a shared library. You probably should export only
>> +// functions from your library. You shouldn't export variables.
>> +//
>> +// As an example what can happen when you export variables without
>> knowing
>> +// the semantics of copy relocations, assume that you have an exported
>> +// variable of type T. It is an ABI-breaking change to add new members at
>> +// end of T even though doing that doesn't change the layout of the
>> +// existing members. That's because the space for the new members are not
>> +// reserved in .bss unless you recompile the main program. That means
>> they
>> +// are likely to overlap with other data that happens to be laid out next
>> +// to the variable in .bss. This kind of issue is sometimes very hard to
>> +// debug. What's a solution? Instead of exporting a varaible V from a
>> DSO,
>> +// define an accessor getV().
>>   template <class ELFT> static void addCopyRelSymbol(SharedSymbol<ELFT>
>> *SS) {
>>     typedef typename ELFT::uint uintX_t;
>>   @@ -482,10 +497,10 @@ template <class ELFT> static void addCop
>>     // Look through the DSO's dynamic symbol table for aliases and create
>> a
>>     // dynamic symbol for each one. This causes the copy relocation to
>> correctly
>>     // interpose any aliases.
>> -  for (SharedSymbol<ELFT> *Alias : getSymbolsAt(SS)) {
>> -    Alias->NeedsCopy = true;
>> -    Alias->Section = ISec;
>> -    Alias->symbol()->IsUsedInRegularObj = true;
>> +  for (SharedSymbol<ELFT> *Sym : getSymbolsAt(SS)) {
>> +    Sym->NeedsCopy = true;
>> +    Sym->Section = ISec;
>> +    Sym->symbol()->IsUsedInRegularObj = true;
>>     }
>>       In<ELFT>::RelaDyn->addReloc({Target->CopyRel, ISec, 0, false, SS,
>> 0});
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170220/2dc5d421/attachment.html>