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

[Ed Maste via llvm-commits]

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.