[lld] r251526 - [ELF2] R_X86_64_COPY relocation implemented

[Rui Ueyama via llvm-commits]

On Mon, Nov 2, 2015 at 8:17 AM, George Rimar via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> >> +  // Can have offset if requires copy relocation.
> >> +  uintX_t OffsetInBSS = 0;
> >> +  bool NeedsCopy = false;
> >
> >You can drop the bool by initializing OffsetInBSS to -1 and using that
> >to mean that copy relocation is not needed, no?
>
> I dont think it will be enough. In void Writer<ELFT>::scanRelocs() method
> E->NeedsCopy flag is used to determine
> if rela.dyn entry is needed for SharedSymbol or not. Each such copy
> relocation for symbol should be added to rela.dyn only once
> and that is for what this flag was initially added I think.
>
> if (auto *E = dyn_cast<SharedSymbol<ELFT>>(Body)) {
>   if (E->NeedsCopy)
>     continue;
>   E->NeedsCopy = Target->relocNeedsCopy(Type, *Body);
> }
> ....
> Out<ELFT>::RelaDyn->addReloc({C, RI});
>
>
> >> +    const Elf_Sym &Sym = C->Sym;
> >> +    // We don't know the exact alignment requirement for the data
> copied by a
> >> +    // copy relocation, so align that to 16 byte boundaries that
> should be large
> >> +    // enough unconditionally.
> >> +    Off = RoundUpToAlignment(Off, 16);
> >> +    C->OffsetInBSS = Off;
> >> +    Off += Sym.st_size;
> >
> >The alignment of a symbol is less than or equal to the alignment of
> >the section it came from. You can use the alignment of the section in
> >here.
>
> I`ll review that idea later.
> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
>

If we push hard, a symbol alignment can be computed from the section
alignment *and* the offset of the symbol in the section. For example, if
symbol S is at offset 24 in a section whose alignment is 16, S needs to be
aligned on a 8 byte boundary. That's what gold does.

But I don't think we really need that because I think the number of copy
relocations is small. Saving a few bytes doesn't seem to make sense.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151102/496fb414/attachment.html>