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

Rui Ueyama ruiu at google.com
Mon Apr 7 13:33:41 PDT 2014


On Mon, Apr 7, 2014 at 1:13 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:

> On 4/7/2014 2:53 PM, Shankar Easwaran wrote:
>
>> On 4/7/2014 2:27 PM, Joerg Sonnenberger wrote:
>>
>>> (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?
>>>>
>>> No, I really meant ignored. The most you can or should do about them is
>>> check for consistency of the type. Otherwise they are completely
>>> irrelevant. Trying to resolve them is just going to waste time.
>>>
>> The undefined symbol from a shared library may most likely pull in a
>> defined symbol from an archive library which comes later in the link line
>> and the executable may end up exporting it.
>>
>> I am not sure what you meant by ignored ?
>>
>
> Given these oddities of choosing whether we want undefined symbols from
> shared libraries to be picked up/not, its better that lld have a flag like
> what it does right now.
>
> With this undefined symbols would only be picked up for symbol resolution,
> if --use-shlib-undefines would be set. This would be different from Gnu but
> I think its better to be different.
>

I wouldn't think that's a good strategy. What we should do is to figure out
what the expected behavior is, and implement the correct behavior.
Implementing one thing in a variety of ways because we don't know which one
is correct does not sounds like a right approach.

Bigcheese/Joerg ?
>
> Thanks
>
> Shankar Easwaran
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140407/1165a068/attachment.html>


More information about the llvm-commits mailing list