[Gcl-devel] Re: Bug#217484: Bug#204789: gcl segfault on ia64

[Camm Maguire]

Greetings, and thank you so much for your reply on this issue!

Please let me preface the below with the statement that these are, of
course, my opinions only, and that there may well be issues of which
I'm unaware which may contraindicate my conclusions.

Briefly, I think this is a bug in libc6 because:

1) It makes stable unexeced binary images, to my understanding,
   impossible.  Unexecing, while by no means the dominant method for
   making binaries, has a long history in unix, most notably serving
   at the base of emacs compilation, but also in like manner gcl and
   the (growing number of) images build atop gcl, currently maxima,
   acl2, and axiom.  I believe that for some time this issue stood in
   the way of an emacs on ia64 linux.  Apparently there has been some
   workaround put in place, but on searching the archives and the code
   base, I cannot find it.  I've had a helpful suggestion from a
   reader of debian-ia64 that I should modify the gcl's unexec to dump
   the portion of the descriptor table containing internal function
   addresses into the image itself as a runtime override of ld.so's
   work, but this appears both desperate and fragile.

2) ld.so's changing of the function descriptor table is (apparently)
   unnecessary, albeit possibly permitted by the ABI.  To my
   knowledge, the Debian port to hppa faced similar issues, yet the
   implementation arrived at is free of this problem.  In addition,
   the same helpful respondent referred to above suggested three ways
   in which this problem could be addressed at the ld.so level:

=============================================================================
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?

=============================================================================

3) The ld.so ia64-specific behavior is clearly the root of the tree of
   these problems, and is the logical place to address them all once
   and for all.  And, unless the ABI mandates that the descriptors
   *must* change across runs, implementing the descriptor table
   creation in a manner consistent with function addressing use on all
   the other Debian platforms is bound to improve the consistency,
   continuity, and robustness of the distro as a whole.  To be more
   precise, the alternative to an ld.so fix is for every program from
   now on which ever uses unexec to put in and maintain lengthy ia64
   specific #ifdef'ed modifications.

Anyway, these are just my thoughts.

Take care,


Daniel Jacobowitz <address@hidden> writes:

> On Sat, Oct 25, 2003 at 02:04:47PM -0400, Camm Maguire wrote:
> > reaassign 217484 libc6
> > severity 217484 important
> > merge 217484 204789
> > thanks
> > 
> > Greetings!  This is due to the way libc6 on ia64 Debian linux (only)
> > recalculates function descriptors at runtime depending on the exact
> > version of the shared libs present, ostensible soname compatibility
> > notwithstanding.  A simple recompile on the box on which gcl will run
> > is a workaround.  If this cannot be fixed, we will have to ensure gcl
> > is synchronized with its shared lib dependency packages when
> > finalizing sarge.
> 
> I still don't understand why you consider this behavior to be a bug in
> libc6.  The ia64 ABI does not promise that function descriptors will
> remain constant even across runs, as far as I know.
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah