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

[Rui Ueyama via llvm-commits]

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