[PATCH] Limited export of dynamic syms (elf32)
Andreas Jaeger
aj@suse.de
Thu Aug 16 10:04:00 GMT 2001
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
More information about the Binutils
mailing list