ia64 function descriptors and unexec

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 <dan@debian.org> 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			     			camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Re: ia64 function descriptors and unexec

[Andreas Schwab]

Camm Maguire <camm@enhanced.com> writes:

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

There is no problem with statically initialized function pointers, only
for assigned pointer at runtime.  The function descriptors for the former
are generated at compile time and won't ever change.

> I believe that this issue stood in the way of an emacs port to ia64
> linux for some time,

There is no such problem with GNU Emacs.  Only XEmacs has this problem.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Re: ia64 function descriptors and unexec

[Camm Maguire]

Greetings, and thanks for your reply!

Andreas Schwab <schwab@suse.de> writes:

> Camm Maguire <camm@enhanced.com> writes:
> 
> > 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.
> 
> There is no problem with statically initialized function pointers, only
> for assigned pointer at runtime.  The function descriptors for the former
> are generated at compile time and won't ever change.
> 

OK, but I need saved runtime-initialized function pointers.  Do you
have either a reference for how xemacs has handled this, or a contact
person who might know?  Was there ever a GNU emacs obstacle on ia64
linux, or am I confusing the situation with xemacs?

Take care,

> > I believe that this issue stood in the way of an emacs port to ia64
> > linux for some time,
> 
> There is no such problem with GNU Emacs.  Only XEmacs has this problem.
> 
> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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

Re: [Gcl-devel] Re: ia64 function descriptors and unexec

[Andreas Schwab]

Camm Maguire <camm@enhanced.com> writes:

> OK, but I need saved runtime-initialized function pointers.  Do you
> have either a reference for how xemacs has handled this, or a contact
> person who might know?

I have hacked XEmacs to re-assign all those function pointers, good enough
to get it running.  But this hack is too ugly, so I never bothered to send
the patch upstream (I also never used XEmacs myself, so I don't care
much).  I've heard that the current version of XEmacs use a different
dumper which doesn't have this problem any more, but I didn't test it yet.

>  Was there ever a GNU emacs obstacle on ia64 linux, or am I confusing
> the situation with xemacs?

Since GNU Emacs does not assign function pointers at runtime there was
never such a problem.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Gcl-devel] Re: ia64 function descriptors and unexec

[Peter Chubb]

>>>>> "Andreas" == Andreas Schwab <schwab@suse.de> writes:

Andreas> Camm Maguire <camm@enhanced.com> writes:

Andreas> I have hacked XEmacs to re-assign all those function
Andreas> pointers, good enough to get it running.  But this hack is
Andreas> too ugly, so I never bothered to send the patch upstream (I
Andreas> also never used XEmacs myself, so I don't care much).  I've
Andreas> heard that the current version of XEmacs use a different
Andreas> dumper which doesn't have this problem any more, but I didn't
Andreas> test it yet.

Well the version packaged for Debian on IA64 still does not work:
Bug #149088 in the debian bug tracking system.

Peter C

Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec

[Stephen J. Turnbull]

>>>>> "Peter" == Peter Chubb <peter@chubb.wattle.id.au> writes:

    Peter> Well the version [of XEmacs] packaged for Debian on IA64
    Peter> still does not work: Bug #149088 in the debian bug tracking
    Peter> system.

--with-system-malloc seems to be necessary and sufficient on Red Hat
Linux systems for the ia64 architecture to work.

Does the Debian packaged version use the portable dumper option?


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: [Gcl-devel] Re: ia64 function descriptors and unexec

[Peter Chubb]

>>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes:

>>>>> "Peter" == Peter Chubb <peter@chubb.wattle.id.au> writes:
Peter> Well the version [of XEmacs] packaged for Debian on IA64 still
Peter> does not work: Bug #149088 in the debian bug tracking system.

Stephen> --with-system-malloc seems to be necessary and sufficient on
Stephen> Red Hat Linux systems for the ia64 architecture to work.

That option *is* included in the configure line.

Stephen> Does the Debian packaged version use the portable dumper
Stephen> option?

Yes.


--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories,   all slightly different.

Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec

[Richard Stallman]

If this is an issue about xemacs only, please omit emacs-devel from further
messages.

Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec

[Camm Maguire]

Greetings!

Andreas Schwab <schwab@suse.de> writes:

> >  Was there ever a GNU emacs obstacle on ia64 linux, or am I confusing
> > the situation with xemacs?
> 
> Since GNU Emacs does not assign function pointers at runtime there was
> never such a problem.
> 

Could you please sketch how this is accomplished in emacs, given its
lisp base?  I.e. as one initializes the lisp when building emacs, does
one not create function objects containing pointers/function addresses
which are then dumped in the unexec?  Or are all lisp function objects
statically defined in C source files as explicitly initialized
structures? 

Take care,

> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> 
> 
> 

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

Re: [Gcl-devel] Re: ia64 function descriptors and unexec

[Andreas Schwab]

Camm Maguire <camm@enhanced.com> writes:

> Greetings!
>
> Andreas Schwab <schwab@suse.de> writes:
>
>> >  Was there ever a GNU emacs obstacle on ia64 linux, or am I confusing
>> > the situation with xemacs?
>> 
>> Since GNU Emacs does not assign function pointers at runtime there was
>> never such a problem.
>> 
>
> Could you please sketch how this is accomplished in emacs, given its
> lisp base?
[...]
> Or are all lisp function objects statically defined in C source files as
> explicitly initialized structures?

Yes.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Bug#204789: [Gcl-devel] Re: ia64 function descriptors and unexec

[Camm Maguire]

Greetings!

Andreas Schwab <schwab@suse.de> writes:

> Camm Maguire <camm@enhanced.com> writes:
> 
> > Greetings!
> >
> > Andreas Schwab <schwab@suse.de> writes:
> >
> >> >  Was there ever a GNU emacs obstacle on ia64 linux, or am I confusing
> >> > the situation with xemacs?
> >> 
> >> Since GNU Emacs does not assign function pointers at runtime there was
> >> never such a problem.
> >> 
> >
> > Could you please sketch how this is accomplished in emacs, given its
> > lisp base?
> [...]
> > Or are all lisp function objects statically defined in C source files as
> > explicitly initialized structures?
> 
> Yes.
> 

These three very helpful little letters have given me the idea which I
hope will be a stable once and for all solution to this problem and
any future others like it.  Far better than trying to probe ld.so's
function descriptor table, I should rather ammend the lisp compiler to
write a static function structure into each produced C source file
before compilation, with the structure's pointer element statically
initialized to the static function in the same file.  I then use the
address for this structure at runtime in setting the lisp symbol's
function definition.  This should work, right?

Take care,


> Andreas.
> 
> -- 
> Andreas Schwab, SuSE Labs, schwab@suse.de
> SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
> Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
> 
> 
> 

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