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

[Hal Finkel via llvm-commits]

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/Relocations.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