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

[Rui Ueyama via llvm-commits]

Do you need more than that?

On Tue, Feb 16, 2016 at 2:26 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> 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/c37b268a/attachment.html>