<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 5, 2015 at 11:02 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I guess my point is that, if -r offers no real value to users, we may not<br>
> want to support that and instead recommend users use ar.<br>
<br>
</span>Fair enough. I don't know how many users there are.<br>
<br>
I just tested with gold and bfd. All the relocation are still in the output.<br>
<br>
So I think I agree. We should delay this until either<br>
<br>
* There is evidence that there are lots of ld -r users.<br>
* We implement relocation resolution as an optimization and it is profitable.<br></blockquote><div><br></div><div>I agree with that.</div><div><br></div><div>(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.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Now that I look at it, -r is pretty odd, it combines the sections with<br>
the same name. So it is not good for fast linking (same relocs) and it<br>
is not good for optimizations (--gc-sections can't do much).<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>