[M3devel] limiting .so exports

[Jay K]

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