[Mono-dev] A question on Mono and -Bsymbolic

Paolo Molaro lupus at ximian.com
Tue Jan 30 13:17:52 EST 2007

On 01/26/07 H. J. Lu wrote:
> My optimization is to remove those extra PLT relocations and jumps
> at link-time.  People reported:

That would be great.

> There are some performance numbers at
> http://sourceware.org/bugzilla/show_bug.cgi?id=3831#c13

I doubt we'd get much performance improvements, but it sure sounds like 
a worthwhile optimization.

> One side effect is you can no longer override global functions in a
> shared libraries. Does it work with Mono shared libraries? If not,
> is there a list of Mono functions which have to be overridable by
> another shared library or user?

Do you plan to enable this feature by default?
Anyway, there is one case where this could cause problems for us if
enabled by default, if I understand things correctly.

Our setup is like this:
*) the mono runtime is implemented in a library, libmono
*) for speed, memory usage and debuggability issues, the mono binary
is statically linked to libmono
*) the runtime exposes a C API for profiling: profilers can be written
independently and compiled to shared libraries. The profiler uses
symbols from the embedding and profiling C API exposed by libmono:
the profile shared lib is linked against the dynamic libmono.
*) the mono binary loads the profiler module with dlopen: for it to work
the symbols must be resolved against the mono binary (typically a
function to register callbacks that happen during the program run)

Now the scenario can get complicated and I guess this may not even work
today if it happens (we'll always be able to fix the issue by
dynamically linking the mono binary...): if the profiler module uses a
symbol from libmono that the linker removed from the mono binary
(because it looks unused), the function from libmono will be used
and any other function it will call will come from libmono and not mono,
with the proposed change. I guess that depending on the nature of the
missing function things may work or not currently as well.

So, in the end, the change shouldn't be a problem for us.


lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better

More information about the Mono-devel-list mailing list