[PATCH] D37574: [ELF] - Do not merge sections from SHT_GROUP when -relocatable

[David Blaikie via llvm-commits]

On Fri, Sep 8, 2017 at 3:52 PM Rui Ueyama via Phabricator via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> ruiu added a comment.
>
> > What is intention of relocatable link and why it is called "partial
> linking" ? As far I understand intention is to speedup final link.
> > When we have multiple .text sections for example, then relocatable link
> merge them by name to output .text. Merging of sections helps to reduce
> amount of
> >  input sections for latter final link. We also merge SHT_REL[A] sections
> when doing that, it should probably help to speedup futher relocation
> processing as well.
> >  As a last resort is also consistent with GNU linkers, it may be
> dangerous to deviate without solid reason as all kind of tools may rely on
> this behavior.
>
> I don't agree. As we have found when you tried to implement the -r option,
> a lot of information that can be merged are passed through instead of being
> merged for a relocatable link. If sections have to be merged for some
> reason, that is fine, but both "-r is for speeding up the linking" and
> "doing something different than GNU linkers is dangerous" are not
> convincing arguments.
>

FWIW, I think that's the point of -r: to merge the sections that can be
merged. I've certainly used this to construct interesting debug info test
cases (merging two objects together to get non-zero debug_info offsets and
the like).

If -r didn't do that (instead keeping all the sections separate, having
multiple (non-comdat differentiated) .text sections, etc), I'd be a bit
surprised/confused.


>
>
> https://reviews.llvm.org/D37574
>
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170911/a04b83b6/attachment.html>