HA: [PATCH] D14382: [ELF2] - Basic implementation of -r/--relocatable
Rui Ueyama via llvm-commits
llvm-commits at lists.llvm.org
Thu Nov 5 11:11:32 PST 2015
On Thu, Nov 5, 2015 at 11:02 AM, Rafael EspĂndola <
rafael.espindola at gmail.com> wrote:
> > I guess my point is that, if -r offers no real value to users, we may not
> > want to support that and instead recommend users use ar.
>
> Fair enough. I don't know how many users there are.
>
> I just tested with gold and bfd. All the relocation are still in the
> output.
>
> So I think I agree. We should delay this until either
>
> * There is evidence that there are lots of ld -r users.
> * We implement relocation resolution as an optimization and it is
> profitable.
>
I agree with that.
(One possibility I can imagine in which relocation resolution could be
profitable is that that's easy to parallelize. We can run ld -r for each
subdirectory in parallel and then do the final link using combined object
files. But I'm not sure that could really be profitable since we can
parallelize the linker itself using threads. So it's important that the
option is proved to be useful with relocation resolution.)
Now that I look at it, -r is pretty odd, it combines the sections with
> the same name. So it is not good for fast linking (same relocs) and it
> is not good for optimizations (--gc-sections can't do much).
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151105/738e05b9/attachment.html>
More information about the llvm-commits
mailing list