<p dir="ltr">For a first implementation I think se should just copy all Relocations. </p>
<div class="gmail_quote">On Feb 16, 2016 5:07 PM, "Rui Ueyama" <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm not happy to admit, but I have to agree that we probably need to support this. go.test use case doesn't seem convincing, but other uses seem legitimate (although pretty hacky) and not easily replaceable with other means. If we do not want to be the system linker of the FreeBSD operating system, we would be able to just ignore that, but obviously I want it to be the default system linker.<div><br></div><div>Rafael, do you want to apply and remove some relocations? If I remember correctly, other linkers don't remove any relocations when ld -r, but just copy all relocations to the resulting .o file.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 1:30 PM, 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">I think there is enough evidence to say that we will probably have to<br>
implement -r. The remaining question IMHO is when. Since this involves<br>
relocations, my preference would be to do it once we are happy with<br>
the way we handle relocations in a regular link. In particular, we<br>
have to find a clean way of implementing relocation optimizations like<br>
"load from got" -> lea.<br>
<br>
Rui, do you have an opinion on it?<br>
<br>
Cheers,<br>
Rafael<br>
<br>
<br>
On 16 February 2016 at 16:20, Ed Maste via llvm-commits<br>
<div><div><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<br>
> I'd like to pick up the discussion about -r (relocatable output) support in lld.<br>
><br>
> On 18 November 2015 at 17:01, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
>><br>
>> Thanks for the info. I saw some need for -r, and I agree that this is just<br>
>> one case and there would be other use cases in the wild. At the same time, I<br>
>> feel like they do that way since the linker supports that feature, which<br>
>> could have been done in a different way. They could update the code to<br>
>> remove dependency to the -r functionality. (I'm happy to contribute such<br>
>> patch to a project that uses -r.) It is much harder to remove a feature than<br>
>> adding, so I'd want to be conservative now.<br>
><br>
> I came back to look at this now because I've started trying to build<br>
> and test llvm/clang/lldb/lld linked with lld again. check-llvm fails<br>
> because Bindings/Go/go.test uses -r:<br>
><br>
> FAIL: LLVM :: Bindings/Go/go.test (2514 of 15889)<br>
> ******************** TEST 'LLVM :: Bindings/Go/go.test' FAILED<br>
> ********************<br>
> [...]<br>
> Command Output (stderr):<br>
> --<br>
> # <a href="http://llvm.org/llvm/bindings/go/llvm" rel="noreferrer" target="_blank">llvm.org/llvm/bindings/go/llvm</a><br>
> CC: warning: argument unused during compilation: '-pthread'<br>
> -r option is not supported. Use 'ar' command instead.<br>
> CC: error: linker command failed with exit code 1 (use -v to see invocation)<br>
><br>
> The "Use 'ar' command instead." suggestion isn't sufficient as there<br>
> are valid uses for -r that are not addressed by ar.<br>
><br>
> In FreeBSD we have:<br>
> 1. Static libpam, using a linker set to simulate loadable modules<br>
> 2. crunchgen(1) to build the rescue(8) binary<br>
> 3. i386 C startup (csu)<br>
> 4. i386 boot components (kgzldr & btx)<br>
> 5. usr.sbin/uathload (basically using ld -r for objcopy)<br>
><br>
> ar isn't usable for any of these, and all but #5 rely on ld -r. The<br>
> objcopy case in #5 isn't something we want to support in lld I think.<br>
> #2, #3 and #4 all combine multiple objects into a single .o and rely<br>
> on symbol resolution between those objects to avoid conflicts when<br>
> further linking the output with other objects.<br>
</div></div><div><div>> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div>