__libc_ia64_register_backing_store_base
Greetings! GCL uses the above externally defined address in locating
the special second stack on ia64 for the purposes of garbage collection
(standard mark/sweep). All works fine, as long as gcl is run with the
same libc with which it was compiled, otherwise there are symptoms of
memory corruption. As this only occurs on ia64, which is also the only
architecture with this special code in the garbage collector, I
suspect this variable is the culprit, though it could also be some
issue with ld.so on ia64 only, I suppose.
I'd hate to statically link in libc on this arch. Another approach
would be to alter gcl's depends to require the identical libc at
runtime, but this is also less than optimal. I'm hoping that some of
this might ring a bell with someone on this list, and there might be a
better way to locate the stack independently of the libc version. I'd
also like a good way to simulate this other than to wait for a new
libc in unstable and watch for failure :-(.
Any pointers appreciated,
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: