[lld] process undefined atoms from shared library only once

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[lld] process undefined atoms from shared library only once

Shankar Easwaran
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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [lld] process undefined atoms from shared library only once

Rui Ueyama
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 <[hidden email]> 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



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [lld] process undefined atoms from shared library only once

Shankar Easwaran
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


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
> <[hidden email]>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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: [lld] process undefined atoms from shared library only once

Michael Spencer-4
On Tue, Nov 19, 2013 at 12:04 PM, Shankar Easwaran
<[hidden email]> 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
>> <[hidden email]>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
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev