[PATCH] [ELF] Fix undefined symbol handling in DSO.

[Rui Ueyama]

On Mon, Apr 7, 2014 at 3:32 AM, Joerg Sonnenberger
<joerg at britannica.bec.de>wrote:

> On Sun, Apr 06, 2014 at 09:58:13PM -0700, Rui Ueyama wrote:
> > Currently LLD ignores undefined symbols found in DSOs when linking
> against
> > DSO files, if -shared flag is given. Internally, it's achieved by
> enabling
> > "useShlibUndefines" flag, which makes the file reader to ignore all
> undefined
> > symbols in DSO, so that Resolver don't see any undefined symbols when
> > handling DSO files.
>
> I don't think your patch fixes the real issue. The correct behavior
> is:
>
> (1) If the undefined symbol comes from an object file (or archive
> library), it is a true undefined symbol. In this case, the behavior
> depends on (a) -z defs (b) the output type. For shared libraries,
> undefined symbols are by default not fatal, for executables, they are.
>

That's I believe already implemetned correctly. Please take a look at
GnuLdDriver.cpp:295.

 (2) Undefined symbols in shared libraries pulled in via -l are ignored.
>

By "ignored", I'd think you mean "undefined symbol from library is not
fatal", right? GNU LD does not completely ignore undefined symbols from
library files, they instead just don't warn on remaining undefined symbols
if they are from a library. GNU LD tries to resolve undefined symbols even
if they are from library.

(3) For ELF, shared libraries are processed recursively.
>

Are you talking about runtime behavior? Could you elaborate a bit?


> Joerg
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140407/8bc81722/attachment.html>