gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel Jacobowitz
Subject: [Gcl-devel] Re: Bug#217484: Bug#204789: gcl segfault on ia64
Date: Tue, 28 Oct 2003 11:57:00 -0500
User-agent: Mutt/1.5.1i

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.

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

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

> 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
them.  It can not be solved contained in glibc.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer




reply via email to

[Prev in Thread] Current Thread [Next in Thread]