[MLton] symbol scopes

[Matthew Fluet]

On Wed, 12 Nov 2008, Wesley W. Terpstra wrote:
> On Wed, Nov 12, 2008 at 7:17 PM, Matthew Fluet <fluet at tti-c.org> wrote:
>> But, for Darwin, both EXTERNAL and PUBLIC map
>> to the same annotation --- is the MLton x86/amd64 codegen for Darwin simply
>> avoiding a cleanup step that would be performed by the linker (if we treated
>> 'public' as 'external')?
>
> I'm not sure what you're asking me..? Currently the darwin codegen
> avoids making PLT stub indirections for public symbols, but that's
> just an optimization.

Effectively, I'm asking how gcc handles the following on Darwin:

z.h:
-----
__attribute__((visibility("default"))) int foo(int);
-----

y.c:
-----
#include "z.h"
int bar(int i) { return (foo(i) + foo(i+1)); }
-----

gcc -c y.c

gcc main.c y.o z.o  --- foo turns out to be 'public'
gcc -lz main.c y.o  --- foo turns out to be 'extern' (-lz satisfied by z.dylib)

It seems to me that at the point that gcc needs to produce object code 
for y.c, it can't know whether it can avoid making PLT stub indirections, 
because it doesn't know if foo will turn out to be 'public' or 'extern'. 
So, it has to use the PLT stub indirections.  The only time that gcc could 
avoid the PLT stub indirections are the cases where there is a use of a 
'public' symbol in the same compilation unit as the definition of the 
'public' symbol.