[LLVMdev] [lld] process undefined atoms from shared library only once

[Michael Spencer]

On Tue, Nov 19, 2013 at 12:04 PM, Shankar Easwaran
<shankare at codeaurora.org> wrote:
> Hi Rui,
>
> I thought about this, but there is a catch. The undefined symbols still need
> to be resolved with exports from dynamic libraries even the second time, or
> any number of times.
>
> For example :-
>
> ld 1.o --start-group libc.so myprintf.a --end-group
>
> 1.o has a undef for myprintf, which is in myprintf.a and myprintf.a calls
> puts.
>
> The first time when libc.so, undef atoms would be added, no shared library
> export atoms would be created because there is nothing that libc.so would
> resolve.
>
> The second time, undefined symbols from shared libraries need to be skipped,
> and the external symbols that are present in the shared library libc.so need
> to be looked at.
>
> To complicate things there is also --as-needed/--no-as-needed, where in a
> shared library is used only if its resolving symbols(the linker may need to
> handle undefined symbols/external symbols from shared library in any
> iteration).
>
> Thanks
>
> Shankar Easwaran

In the --no-as-needed case you just add all the atoms when you hit the
library, and you're done. For the --as-needed case you need to only
add the undefs if something is resolved from it, and then skip it in
the future.

- Michael Spencer

>
>
>
> On 11/19/2013 1:49 PM, Rui Ueyama wrote:
>>
>> I'd do that with the nextFile abstraction like this: On the first
>> iteration, a Group would return its member every time getNextFile() is
>> called (the same as the current behavior). On the second and further
>> iterations, the Group should skip all the members whose type is not
>> Archive. By doing this, the core linker sees dynamic libraries (or regular
>> object files) only once even if they are in --{start,end}-group.
>>
>>
>> On Mon, Nov 18, 2013 at 11:03 PM, Shankar Easwaran
>> <shankare at codeaurora.org>wrote:
>>
>>> Hi Nick,
>>>
>>> --start-group/--end-group functionality with the Gnu flavor currently
>>> works only if the --start-group/--end-group contains archive files.
>>>
>>> If they contain dynamic libraries, the undefined atoms from the dynamic
>>> libraries are processed whenever the group is iterated again.
>>>
>>> I am trying to find out a way to make the resolver add undefined atoms
>>> from the shared library only *once*, when the SharedLibrary is first
>>> visited as part of the Group.
>>>
>>> The only approach that I can think of is having a std::map in the
>>> resolver
>>> and using that to process undefined atoms from shared libraries the first
>>> time the shared library is visited. I dont like this approach as its not
>>> clean.
>>>
>>> Any alternative approaches to handle this ?
>>>
>>> Thanks
>>>
>>> Shankar Easwaran
>>>
>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
>>> by the Linux Foundation
>>>
>>>
>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by
> the Linux Foundation
>