[PATCH] [Layout] Assign ordinals in resolution order

[Shankar Easwaran]

On 10/9/2013 9:06 PM, Nick Kledzik wrote:
> On Oct 9, 2013, at 6:53 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>> Hi Nick,
>>
>> On 10/9/2013 7:15 PM, Nick Kledzik wrote:
>>> On Oct 8, 2013, at 10:44 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>>>
>>>> On 10/9/2013 12:40 AM, kledzik at apple.com wrote:
>>>>>    It looks to me like the ordinals are assigned to archive members as the members are used.  This will result in unstable output because the lazy loading nature of archives loads the members in some what chaotic way (small changes to what if referenced by initial .o files can radically change the load order of members).
>>>> ELF needs the symbols to appear in resolution order.
>>> Is this so the layout matches the gnu linker? or some semantic issue?
>> Yes it helps to match the layout, so that comparing binaries produced by the Gnu linker and lld would be quite similiar.
>>
>>> I can see that simply appending section content in load order is simple and predictable.  But it just pushes the stability problem off to the resolver.  Now it is important that the archive members are loaded in a stable order.  For instance say you have a couple of .o files on the command line followed by a couple of archives.  After all the object files are loaded and atom graphs merged, you have two undefined symbols foo and bar left to resolve.  Which should the resolver look for first?  That is important because it now effect the layout.  Some possibilities:
>> I dont think the order of unresolved symbols resolved is documented. This is upto each linker to handle.
>>
>> Even if we want to do that, foo and bar are going to pulled from the archive irrespective of the order isnt it ? Am I missing some details here.
> You said you wanted the layout to match gnu linker, but the layout is based on the order in which archive members are loaded, and the order they are loaded depends on the order the undefined symbols are processed.  So, unless the undefined order matches the gnu linker, then the layout will not match either.

Thanks for your reply Nick. It looks like Gnu linker is also following 
the same behavior as Darwin when it comes to how symbols are picked from 
the undefined set for resolution.

cat > 1.c << \!
int main() {
   b();
   c();
   return 0;
}
!

cat > 2.c << \!
int fn1() {
   a();
   return 0;
}
!

cat > a.c << \!
int a() {
   return 0;
}
!

cat > b.c << \!
int b() {
   return 0;
}
!

cat > c.c << \!
int c() {
   return 0;
}
!

gcc -c 1.c 2.c a.c b.c c.c
ar cr lib3.a c.o b.o a.o
ld 1.o 2.o lib3.a -t


===> On running this shows

ld: mode elf_x86_64
1.o
2.o
(lib3.a)a.o
(lib3.a)b.o
(lib3.a)c.o

Thanks

Shankar Easwaran

-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by the Linux Foundation