[M3devel] limiting .so exports

[Jay K]

I'm not sure of much right now, I have to rest and come back.

I'm quite dissatisifed with gcc/gnuld currently.
I don't want to tell the compiler anything really.
I want all function calls to always use x86 0xE8 opcode which is a direct pc-relative call, and then have the linker generate small stubs for anything that ends up external.
  That is how NT/x86 works and it is reasonably simple and efficient. Cross-.so calls would be slightly penalized, since if you did tell the compiler about them, it might inline the stub at the call. (The NT/x86 stubs are just one jmp instruction, but they aren't necessarily position-independent).
And I want to mostly give the linker a list of exports, plus maybe a few source annotations for exports.
I'd like source annotations and the lists to be additive. Maybe the "local: *" in my current code is wrong.


There seem to be so many features/switches, and it is hard/impossible to extract something simple, understandable, efficient.
I have trouble getting a mental model of how ld/ld.so work on most platforms.
The model on NT seems simple..

Attached is what I have so far..but I'm not entirely happy with it..
It is disabled in its current form.

It would also be nice if visibility(protected) worked.
It does sometimes, for calls, but not for taking the address of a function.

Anyway...
 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Thu, 20 May 2010 10:50:42 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] limiting .so exports
>
> 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
>>
>
 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exports.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100520/f98ad3ee/attachment-0002.txt>