Re: [PATCH] Limited export of dynamic syms (elf32)

[Andreas Jaeger <aj at suse dot de>]

Eirik Byrkjeflot Anonsen <eirik@opera.com> writes:

> Andreas Jaeger wrote:
> > 
>> Eirik Byrkjeflot Anonsen <eirik@opera.com> writes:
>> 
>> > I have implemented a possibility for exporting only selected symbols
>> > as dynamic symbols in the elf32 case.
>> 
>> Is this for shared libs or for applications?  What is the advantage of
>> this over symbol versioning?
>> 
>> Andreas
>
>
> I believe it works for both.  The reason for implementing it was
> to make Opera/Linux not export internal symbols that could expose
> parts of the program that we don't want exposed (like the registration
> code...).  Another reason is the possibility of a shared library loaded
> by Opera (like a plug-in) accidentally calling internal functions of
> Opera.  And finally, we saved roughly 1.5 Mb (IIRC) on the final
> executable size.
>
> Given a shared library with only a few functions that
> are supposed to be called, all three of these concerns are quite valid.
> With the addition that the library could accidentally override a symbol
> in another library due to having the same name.

For shared libraries we have this functionality with symbol versioning
already.  You can define a map file containing e.g. (this is from
glibc's librt):

GLIBC_2.1 {
  global:
    aio_cancel; aio_cancel64; aio_error; aio_error64; aio_fsync; aio_fsync64;
    aio_init; aio_read; aio_read64; aio_return; aio_return64; aio_suspend;
    aio_suspend64; aio_write; aio_write64; lio_listio; lio_listio64;
  local:
    *;
};

And the library will only export the named interfaces, everything else
is not exported.  I don't see a difference between this and your extension.

I'm not sure whether this works for executables also - but IMO it
would make more sense to extend if it it not works than to introduce
something new.  

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj