[Gcl-devel] ia64 function descriptors and unexec

[Camm Maguire]

Greetings!  I've added Bdale and emacs-devel to the CC list, as I
believe they have already found some work around for gnu emacs, a
description of which would help me greatly.

To sum up the previous discussion, the ia64 linux ABI apparently
offers no opportunity for ld.so to ensure that function descriptors
remain constant, even over successive executions of the same binary on
the same machine.  Any unexec'ed image which has saved "function
pointers" in its .data section will therefore likely be corrupt on
re-execution, as the saved function descriptors, even when simply
referring to functions in the same program, will likely not correspond
to the freshly allocated new ones.

I believe that this issue stood in the way of an emacs port to ia64
linux for some time, and that Bdale contributed a fix, but I can't
find it in the archives or in the current source.

GCL's best bet now appears to be to implement this work around if
possible, and if not, to try to find and dump the old ld.so function
descriptor table into the saved image at unexec time.

Help much appreciated!

A few other comments below:

Daniel Jacobowitz <address@hidden> writes:

> On Tue, Oct 28, 2003 at 11:49:38AM -0500, Camm Maguire wrote:
> > 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 has never, however, worked portably.  I think emacs even
> moved away from it, though I'm not sure of that.
> 

To my knowledge, emacs still uses unexec.  Xemacs uses something
else. 

> >    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.
> 
> The alternatives are also desperate and fragile.  That at least limits
> the damage to gcl.
> 

Fair enough.  Didn't know how bad those suggestions would be vis a vis
libc6. 

> > 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:
> 
> The way that hppa does this is, I think, very different.  Two of the

Do you mean the ABI is different, i.e. does provide an opportunity to
ensure constant function descriptors?  To my knowledge, hpux on this
hardware has the same issue, yet (Debian) linux is free from it.

> suggestions below require substantial changes to the static linker and
> some fudging with the ABI.  Using sbrk would probably not solve the
> issue at all.

I understand that such changes may be inadvisable due to the scope of
both the work required and the functionality affected, but,
hypothetically speaking, would such an implementation once achieved 1)
still conform to the ABI, 2) operate stably, and 3) be arguably
preferable from a design standpoint?  

For the sake of the new readers, these suggestions were:

=============================================================================
> 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.
> 
> There is a flaw in your logic.  It's not "the ABI mandates that the
> descriptors *must* change across runs" so much as "the ABI offers no
> opportunity to *ensure* that descriptors do not change across runs".
> 
> If anything this is a problem with the ia64 linux ABI; take it up with

You know, if I can find the time, I just might, as this appears quite
broken.  Its obviously too late for ia64, but I've heard that similar
things are in the plans for newer arches, and I think some feedback on
this issue should be heard before this problem spreads.  To whom
should I write?

> them.  It can not be solved contained in glibc.
> 

I take it this means cooperation would be needed from ld/gcc.

Thanks for your very helpful reply!  I'm going to look for a gcl
work-around now (as the changes required otherwise are too far
reaching to be good for Debian as a whole), and if I can find one,
I'll drop this bug completely.

Take care,


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