[OLSR-users] MIPS crash problem solved

[Bruno Randolf]

hi thomas!

thanks for figuring this out :)

this is nearly it... it works, but only if the libraries are liked with the 
version-script - wether olsrd is linked with or without the version-script 
does not seem to matter. 

and we cannot hide all symbols, since olsrd expects some of them. so i had to 
use this linker-script:

VERS_1.0 {
   global:
        plugin_interface_version;
        plugin_io;
        register_olsr_data;
   local: *;
};

but i can load the libraries now, thanks a lot, thomas! 

bruno


On Thursday 04 November 2004 17:59, Thomas Lopatic wrote:
> Hi there,
>
> We've finally found the culprit. Thanks to Sven-Ola and Bruno for their
> help!
>
> Also thanks to the people on the binutils mailing list for not screaming
> at me and patiently directing me to the relevant section of the binutils
> documentation! :-)
>
> The problem is that olsrd contains some functions and variables that
> have the same names as some functions and variables in the plugin. On
> Intel Linux this does not lead to any problems, as the functions and
> variables in the plugin are separated from the functions and variables
> in olsrd.
>
> On MIPS, however, this is different, for whatever reason. The functions
> and variables in olsrd interfere with the functions and variables in the
> plugin. The resulting confusion makes olsrd crash on (some versions of)
> the MIPS platform when plugins are loaded.
>
> Although the Linux manual page makes you think otherwise at first sight,
> it is never guaranteed that the functions and variables in olsrd (i.e.
> the executable) do not interfere with the functions and variables in
> plugins (i.e. shared objects loaded by the executable). It's just a
> lucky coincidence that it works like this on Intel.
>
> So, after all, this is not a bug in the MIPS toolchain. True, the MIPS
> toolchain behaves differently from the Intel toolchain. However, this
> behaviour is by design and not a bug, as I've just learned on the
> binutils mailing list.
>
> There is a way to force the functions and variables in the plugin to
> remain separate from the functions and variables in olsrd. This works
> either via GCC by assigning an attribute to functions and variables in
> olsrd, as in
>
> int i __attribute__ ((visibility ("hidden")));
>
> The "hidden" attribute limits the scope of symbols in olsrd to olsrd. No
> interference with shared objects, i.e. plugins.
>
> Alternatively this works by means of "version scripts" that can be
> passed to the linker and which also specify which functions and
> variables from olsrd are to be seen by the plugin and vice versa. The
> nice thing about version scripts is that we do not have to apply the
> "hidden" attribute to each and every function and variable in olsrd.
>
> So, while the traditional "static" limits the scope of a symbol to a
> single object file, "hidden" visibility limits the scope of a symbol to
> a single executable or shared object file.
>
> A version script that sets the scope of all symbols to hidden would look
> as follows.
>
> VERS_1.0 {
>    local: *;
> };
>
> The "*" means "all symbols" and "local" means "hidden" visibility. Could
> somebody try this out, save this version script as "version.txt", and
> pass it to the link step via "-Wl,--version-script=version.txt"? I'm
> pretty curious whether this will work...
>
> -Thomas
>
> _______________________________________________
> olsr-users mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20041104/16d7400a/attachment.sig>