mipsel-linux and --export-dynamic

mipsel-linux and --export-dynamic

[Thomas Lopatic]

Hi there,

I've compiled binutils 2.15 on an Intel Linux platform with a target of 
mipsel-linux ("./configure --target=mipsel-linux"). I am using this 
build to link objects generated by a cross-plattform GCC. My problem is 
that all external symbols end up in the dynamic symbol table (verified 
with "objdump --dynamic-syms"), although I do not pass 
"--export-dynamic" to the linker.

The problem with this is that I have an executable and shared objects 
loaded by this executable that have conflicting symbols, i.e. some 
symbols appear in the executable as well as in the shared objects. So, 
if an external variable "x" appears in the executable and in a shared 
object, both access the same memory location. I would, however, prefer 
everyone to have his own copy of "x". (Because otherwise the program 
crashes. :-D)

Working around the problem by renaming the symbols in the shared objects 
or the executable to remove the overlaps or making the affected 
variables static would be possible in my case. However, I'd prefer the 
linker to behave as expected. Or is there something that I am missing?

If this is not a known issue, I'll be happy to try to reproduce this 
with the latest binutils CVS version.

Would it also make sense to try to reproduce this with the latest CVS 
version of GCC? I don't know much about ELF, but a symbol is a symbol is 
a symbol, isn't it? So the GCC version shouldn't have any impact on this 
problem, should it?

Thanks for your time
-Thomas

Re: mipsel-linux and --export-dynamic

[Daniel Jacobowitz]

On Thu, Nov 04, 2004 at 12:51:02PM +0100, Thomas Lopatic wrote:
> Hi there,
> 
> I've compiled binutils 2.15 on an Intel Linux platform with a target of 
> mipsel-linux ("./configure --target=mipsel-linux"). I am using this 
> build to link objects generated by a cross-plattform GCC. My problem is 
> that all external symbols end up in the dynamic symbol table (verified 
> with "objdump --dynamic-syms"), although I do not pass 
> "--export-dynamic" to the linker.
> 
> The problem with this is that I have an executable and shared objects 
> loaded by this executable that have conflicting symbols, i.e. some 
> symbols appear in the executable as well as in the shared objects. So, 
> if an external variable "x" appears in the executable and in a shared 
> object, both access the same memory location. I would, however, prefer 
> everyone to have his own copy of "x". (Because otherwise the program 
> crashes. :-D)

If you need this behavior, then you should be marking "x" as a hidden
symbol - see the visibility attribute in the GCC manual.

> Working around the problem by renaming the symbols in the shared objects 
> or the executable to remove the overlaps or making the affected 
> variables static would be possible in my case. However, I'd prefer the 
> linker to behave as expected. Or is there something that I am missing?

I think this is one of the many quirks of MIPS ELF.

-- 
Daniel Jacobowitz

Re: mipsel-linux and --export-dynamic

[Ian Lance Taylor]

Thomas Lopatic <thomas@lopatic.de> writes:

> I've compiled binutils 2.15 on an Intel Linux platform with a target
> of mipsel-linux ("./configure --target=mipsel-linux"). I am using this
> build to link objects generated by a cross-plattform GCC. My problem
> is that all external symbols end up in the dynamic symbol table
> (verified with "objdump --dynamic-syms"), although I do not pass
> "--export-dynamic" to the linker.

Note that the MIPS compiler will pass --export-dynamic to the linker
if you use the -rdynamic option.  Not that I have any reason to think
that you are using that.  Are you sure that all external symbols get
exported?  For example, the linker will normally export every called
function, which may indeed be most of the non-static functions.

> The problem with this is that I have an executable and shared objects
> loaded by this executable that have conflicting symbols, i.e. some
> symbols appear in the executable as well as in the shared objects. So,
> if an external variable "x" appears in the executable and in a shared
> object, both access the same memory location. I would, however, prefer
> everyone to have his own copy of "x". (Because otherwise the program
> crashes. :-D)
> 
> Working around the problem by renaming the symbols in the shared
> objects or the executable to remove the overlaps or making the
> affected variables static would be possible in my case. However, I'd
> prefer the linker to behave as expected. Or is there something that I
> am missing?

Using the same symbol name in multiple objects in a link, and relying
on the linker to not export the symbol name by default, is very
fragile.  You should instead use version scripts when you create the
shared library to make only the desired symbols publically visible.
Or you should use the compiler "visibility" attribute.  See the
documentation.

Ian

Re: mipsel-linux and --export-dynamic

[Thomas Lopatic]

Ian, Daniel,

Thanks a lot for shedding some light on this!

I was just a bit confused because the native Linux linker on my system 
by default only puts the unresolved (imported) symbols, e.g. _printf, 
into the dynamic symbol table. I expected the MIPS cross-linker to 
behave in the same way. So, I thought that this was - quite obviously 
:-) - a quirk.

I cannot verify this right now, but it may very well be the case that 
not all symbols got exported. I just noticed that a lot of the 
externally visible symbols were in the dynamic symbol table. And I 
concluded that the linker was behaving as if "--export-dynamic" had been 
specified. (I used "ld" directly, not via the GCC driver.)

I've had a look at the documentation for version scripts and for the 
visibility attribute and for me version scripts will be the way to go in 
this case.

Quite impressive what you can do with "ld".

Thanks again,
-Thomas

Re: mipsel-linux and --export-dynamic

[Daniel Jacobowitz]

On Thu, Nov 04, 2004 at 05:00:53PM +0100, Thomas Lopatic wrote:
> I cannot verify this right now, but it may very well be the case that 
> not all symbols got exported. I just noticed that a lot of the 
> externally visible symbols were in the dynamic symbol table. And I 
> concluded that the linker was behaving as if "--export-dynamic" had been 
> specified. (I used "ld" directly, not via the GCC driver.)

Please - do not do this!  GCC knows a great deal about how to invoke
ld; if you need to pass extra options it will let you do that too.
Most of the frequently reported bugs involving dynamic symbols, shared
libraries, et cetera are cured by letting the GCC driver do its work.

> I've had a look at the documentation for version scripts and for the 
> visibility attribute and for me version scripts will be the way to go in 
> this case.

You will get marginally better performance if the compiler does this
rather than a version script.

-- 
Daniel Jacobowitz