axiom, acl2, maxima, gcl on ia64
severity 204789 important
tags 204789 ia64
thanks
Greetings! I've just uploaded a -6 which should fix your bug --
thanks for the feedback!
I know you are a key person in the Debian ia64 camp, and I wanted to
bring to you attention a serious obstacle in the way of GCL compiled
applications (currently maxima, acl2, and axiom) on ia64. Briefly,
GCL makes the final image for itself and all these programs via
unexec. Function descriptors referring to functions in the executable
itself are thus stored in the executable's .data section. On ia64
only, ld.so can change the meaning of these function descriptors at
runtime depending on which versions of ostensibly binary-compatible
shared libraries are present, making all such apps crash, usually
with segfaults. Unless some fix can be put in place, all four of
these packages will have to be recompiled on ia64 anytime a new upload
of one of their shared library dependencies (currently
libc6,libreadline4,libncurses5,libgmp,libm,and ld-linux.so) occurs.
The details are in the BTS under 204789. I've received some helpful
feedback, suggesting that I try dumping some of ld.so's memory maps in
the unexec. I will try to find time to experiment with this, but I
feel, and hope you agree, that this is not a very robust solution.
Other helpful ideas involving changes to ld.so's mapping algorithm
were also suggested, and are listed in the BTS as well. Here is a
section of the discussion:
> If this analysis is correct, I suspect there are multiple ways to fix
> the problem:
>
> - One possibility might be to have the link editor reserve the
> necessary space so that make_fptr_table() can map this reserved
> space, rather than allocating anonymous memory via mmap().
> Downside: requires changed to both the link-editor and the runtime
> loader and I'm not sure how the runtime loader would locate the
> reserved-space section.
>
> - Another possibility might be to change make_fptr_table() to use
> sbrk() instead of mmap() when it allocates the descriptor table for
> the main program. Downside: I'm not sure it's safe for the runtime
> loader to change the process' break-value.
>
> - A third possibility might be to materialize function pointers for
> the executable program at link time (rather than at load time). I
> think the ELF symbol resolution rules would allow that, but I'm not
> sure whether it would be easy to make these descriptors visible to
> shared objects.
>
> Hmmh, none of these look terribly attractive to me. Richard, what do
> you think?
I'd be most appreciative if these options could be investigated,
leading hopefully to a fix in ld.so, which would stabilize these four
programs on ia64 once and for all. Is this possible? Can you please
help here?
Take care,
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Reply to: