[M3devel] limiting .so exports

[Tony Hosking]

Can we not just push more information through to the back-ends for import_global/import_procedure?  The front-end would need to know where it found the import (in the local package or in another imported package) but all that information would be derivable from m3linker wouldn't it?




On 20 May 2010, at 09:59, Jay K wrote:

> 
> limiting .so exports
>  (and direct binding to symbols in same .so)
> 
> 
> FYI:
> 
> 
> No clear question here, just a heads up regarding stuff that might be coming.
> 
> 
> 
> I'm working on limiting .so exports to only "what they should be".
> 
> 
> In particular, given:
> 
> INTERFACE Foo;
> 
> PROCEDURE Bar();
> 
> END Foo.
> 
> MODULE Foo;
> 
> PROCEDURE F() = BEGIN ... END F;
> 
> PROCEDURE Bar() = BEGIN F(); END Bar;
> 
> END Foo.
> 
> 
> Foo__F should not exported.
> Foo__Bar should be.
> 
> 
> Today they both would be.
> Or at least in the recent past.
>  I already made a change in parse.c to reduce things.
> 
> 
> However at that level I don't believe we have the needed information.
>   (needs investigation)
> 
> 
> What I have is that in MxOut.m3, I write out all the symbols in
> import_def_syms for modules.
> Plus the _M3 and _I3 symbols.
> 
> 
> That is most of the work.
> However there are missing or non-ideal parts.
> 
> 
> In the config files I then transform the list into the format
> required by the compiler/linker. I was doing the transform in MxOut.m3
> but it was getting to be "too much" work.
> 
> 
> You also need to export anything marked <* EXTERNAL *> in interfaces.
> I can get that list, however I have been using the "trick" of not
> always implementing all EXTERNALs.
> Sometimes the C implementation has #ifdefs around it.
> So that becomes difficult.
> 
> 
> gcc has __attribute__ and #pragma GCC visibility to control things
> also, but this seems to conflict with giving a list in a file to
> the compiler/linker.
> 
> 
> What I have currently is that after compiling any C file, I run
> nm on it to get its symbols.
> 
> 
> I combine the nm output with the MxOut.m3 output.
> 
> 
> Unfortunately that exports more of the C code than intended.
> But code that always was exported -- like all of ThreadPThread.c.
> 
> 
> As well something I haven't fixed yet is that lowercase interface
> contents should not be exported, only capital Interface.
> 
> 
> The list would be presented with
>   GNU ld: --version-script
>   Sun ld: -M for mapfile
>   Mac ld: --export-symbol-list
> 
> 
> Sun ld and GNU ld accept roughly the same input.
> 
> 
> I'm not sure how these two mechanisms compare.
> It could be that it is better to use source/parse.c-level "visibility"
> and not present the lists to the linker.
> In particular that allows for not exporting more of the C.
> 
> 
> I have the "lists" working on Mac but not et Linux (GNU ld) or Solaris.
> 
> 
> The "list" approach should probably at least be used on NT/Cygwin.
> Currently we export everything by mklib enumerating the symbols.
> 
> 
>  - Jay
>