[Openmcl-devel] Advice needed to debug shared library problem

[Gary Byers]

Gee, why didn't I think of that ?  Oh, that's right ... I did.

I considered "fooling with linker flags" to be a better solution
than "fooling with function names" would be, since the issue isn't
that two unrelated functions have the same name, it's that (almost all)
function names in the CCL kernel should not be visible/available for
dynamic linking.

Assuming that one could remember the appropriate args to strip(1),
there's no reason that a stripped lisp kernel should behave differently
than a non-stripped kernel.  (There are may be a few cases - like
catch_exception_raise() on Darwin - where a symbol can't be stripped
because it actually does need to be visible to the dynamic linking
mechanism.)  The reasons why the kernel isn't stripped have to do
with debugging (both via GDB - where the 'symbols' in question don't
have much to do with dynamic linking - and with being able to identify
foreign function addresses via dladdr(), where some versions of dladdr()
only return information about dynamically exported symbols.  If that
restriction's no longer present, or if it never was and I'm simply
confused about that, then other linker flags would be more appropriate.

Given the fact that function names aren't globally unique, then it
might be even better for things in CCL that use dladdr() in error
messages etc. to include the name of the shared object in the message
as well, e.g.,

you crashed in create_stack, defined in /path/to/lx86cl64

rather than just

you crashed in create_stack.

If instead that was reported as:

you crashed in RandomGensymedPrefixThatSomeoneThinksIsAppropriate__create_stack

well, I probably shouldn't say anything about that.





On Wed, 30 Mar 2011, Waldek Hebisch wrote:

> Gary Byers wrote:
>>
>> On Linux, the change to the Makefile(s) seems to be enough: it's OK
>> to have symbols exported from the kernel, but we want a library that
>> references some symbol to look everywhere else (but the kernel) first.
>>
>> Having exported symbols in the kernel is useful for debugging; it
>> allows the kernel debugger to identify a foreign PC value as 'foo+n',
>> where 'foo' is the nearest preceding (external, IIRC) symbol.
>>
>
> I wonder why instead of fooling with linker flags (which may
> easily fail if sombody needs different way of linking) you do
> not take the obvoius approach of renaming offending symbol
> using apropriate prefix.
>
> BTW: The same (even more) applies to the library in question:
> in C public symbol "create_stack" (without a prefix) is a disaster
> waiting to happen.
>
> --
>                              Waldek Hebisch
> hebisch at math.uni.wroc.pl
>
>