[PATCH] [lld] [mach-o]: Initial support for reading dylibs during link.

[Nick Kledzik]

Tim,

There is a couple of dimensions here:

1) The mach-o symbol table has three regions: locals, globals, and undefines.
2) The regions are used differently in .o files than in final linked images. For instance hidden (private extern) defined symbols are in the global region in .o files but move to the locals region in final linked images. Similarly tentative definitions are in the undefines region in .o files but move to the globals region in final linked images.
3) For an “audit trail” the N_PEXT bit remains on symbols which were PEXT in .o file, but non-extern (local) in final linked image.

So, my point was the dylib reader only needs to look a the globals region of the symbol table, but it should also sanity check that only global symbols are in there.

-Nick

On Jun 26, 2014, at 12:35 PM, Tim Northover <t.p.northover at gmail.com> wrote:
> Hi Nick,
> 
> On 26 June 2014 20:20, Nick Kledzik <kledzik at apple.com> wrote:
>> I’m not sure where you are seeing N_PEXT symbols in a dylib that
>> are linkable.  Here is an example to show they are not:
> 
> Ah, I'm seeing "non-external (was private-external)" on mine, from:
> 
> $ cat tmp.c
> __private_extern__ int var = 42;
> $ clang -fPIC -shared tmp.c -o tmp.dylib
> $ nm -nm tmp.dylib
> 0000000000001000 (__DATA,__data) non-external (was a private external) _var
> 
> The symbol seems to be N_PEXT (but not N_EXT) with type N_SECT. The
> absence of N_EXT certainly explains why it's not linkable (by the
> looks of it your libfoo.dylib had the same combination), but the
> question of what to do with a symbol that's both N_EXT and N_PEXT
> remains (assuming that's a valid combination in a .dylib).
> 
> Cheers.
> 
> Tim.