[PATCH] D63564: Add undefined symbols from linker script to output file

[Rui Ueyama via llvm-commits]

On Thu, Jun 20, 2019 at 11:47 PM Fangrui Song via Phabricator <
reviews at reviews.llvm.org> wrote:

> MaskRay added a comment.
>
> In D63564#1551811 <https://reviews.llvm.org/D63564#1551811>, @ruiu wrote:
>
> > Is there any possibility that this is a GNU ld's bug? Their behavior is
> different from their man page, and the thing that defines what is the right
> behavior is usually a manual than an actual behavior.
>
>
> GNU ld's behavior seems consistent: both `EXTERN(foo)` and `-u foo` force
> the undefined symbol `foo`. In lld, I think this option is only useful when
> the symbol exists and is a LazyArchive/LazyObject.
>
> @ihalip To make `foo` appears in .symtab but not in .dynsym for `ld.bfd
> -shared a.o -u test -o a.so` will be difficult. I think another Symbol bit,
> like `ExportDynamic`, will be required to represent this.
>
> Even if we can do that, the semantics of -u will be different from
> `--undefined-glob`. In any case, `-r -u` looks weird to me: if you use the
> partially linked object to link a shared object or an executable, why can't
> you delay the use of `EXTERN(foo)`? So I asked if this issue can be worked
> around in the Linux kernel.
>

That's what I thought too. Since there's no standard as to how these
command line options should work, we cannot say whether some behavior is
correct or wrong with a 100% confidence, but in particular when an option
is used in combination with `-r`, we can think a lot of "right" behaviors,
I wouldn't depend on the current GNU ld's semantics of `-u` and `-r`. I
don't know whether it is an intended behavior or an unintended one. Is it
hard to pass `EXTERN` to the final linker instead of an intermediate linker
that creates a re-linkable object file?



>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D63564/new/
>
> https://reviews.llvm.org/D63564
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190621/2d705102/attachment.html>