[PATCH] D14382: [ELF2] - Basic implementation of -r/--relocatable

[Rafael Espíndola via llvm-commits]

For a first implementation I think se should just copy all Relocations.
On Feb 16, 2016 5:07 PM, "Rui Ueyama" <ruiu at google.com> wrote:

> 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.
>
> 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.
>
> On Tue, Feb 16, 2016 at 1:30 PM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
>
>> I think there is enough evidence to say that we will probably have to
>> implement -r. The remaining question IMHO is when. Since this involves
>> relocations, my preference would be to do it once we are happy with
>> the way we handle relocations in a regular link. In particular, we
>> have to find a clean way of implementing relocation optimizations like
>> "load from got" -> lea.
>>
>> Rui, do you have an opinion on it?
>>
>> Cheers,
>> Rafael
>>
>>
>> On 16 February 2016 at 16:20, Ed Maste via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>> > I'd like to pick up the discussion about -r (relocatable output)
>> support in lld.
>> >
>> > On 18 November 2015 at 17:01, Rui Ueyama <ruiu at google.com> wrote:
>> >>
>> >> Thanks for the info. I saw some need for -r, and I agree that this is
>> just
>> >> one case and there would be other use cases in the wild. At the same
>> time, I
>> >> feel like they do that way since the linker supports that feature,
>> which
>> >> could have been done in a different way. They could update the code to
>> >> remove dependency to the -r functionality. (I'm happy to contribute
>> such
>> >> patch to a project that uses -r.) It is much harder to remove a
>> feature than
>> >> adding, so I'd want to be conservative now.
>> >
>> > I came back to look at this now because I've started trying to build
>> > and test llvm/clang/lldb/lld linked with lld again. check-llvm fails
>> > because Bindings/Go/go.test uses -r:
>> >
>> > FAIL: LLVM :: Bindings/Go/go.test (2514 of 15889)
>> > ******************** TEST 'LLVM :: Bindings/Go/go.test' FAILED
>> > ********************
>> > [...]
>> > Command Output (stderr):
>> > --
>> > # llvm.org/llvm/bindings/go/llvm
>> > CC: warning: argument unused during compilation: '-pthread'
>> > -r option is not supported. Use 'ar' command instead.
>> > CC: error: linker command failed with exit code 1 (use -v to see
>> invocation)
>> >
>> > The "Use 'ar' command instead." suggestion isn't sufficient as there
>> > are valid uses for -r that are not addressed by ar.
>> >
>> > In FreeBSD we have:
>> > 1. Static libpam, using a linker set to simulate loadable modules
>> > 2. crunchgen(1) to build the rescue(8) binary
>> > 3. i386 C startup (csu)
>> > 4. i386 boot components (kgzldr & btx)
>> > 5. usr.sbin/uathload (basically using ld -r for objcopy)
>> >
>> > ar isn't usable for any of these, and all but #5 rely on ld -r. The
>> > objcopy case in #5 isn't something we want to support in lld I think.
>> > #2, #3 and #4 all combine multiple objects into a single .o and rely
>> > on symbol resolution between those objects to avoid conflicts when
>> > further linking the output with other objects.
>> > _______________________________________________
>> > 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/20160216/32c8daef/attachment.html>