[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: Bug#217484: Bug#204789: gcl segfault on ia64
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: Bug#217484: Bug#204789: gcl segfault on ia64 |
Date: |
28 Oct 2003 11:49:38 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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
- [Gcl-devel] gcl segfault on ia64, Camm Maguire, 2003/10/25
- [Gcl-devel] Re: Bug#204789: gcl segfault on ia64, Daniel Jacobowitz, 2003/10/25
- [Gcl-devel] Re: Bug#217484: Bug#204789: gcl segfault on ia64,
Camm Maguire <=
- [Gcl-devel] Re: Bug#217484: Bug#204789: gcl segfault on ia64, Daniel Jacobowitz, 2003/10/28
- [Gcl-devel] ia64 function descriptors and unexec, Camm Maguire, 2003/10/29
- [Gcl-devel] Re: ia64 function descriptors and unexec, Andreas Schwab, 2003/10/29
- Re: [Gcl-devel] Re: ia64 function descriptors and unexec, Camm Maguire, 2003/10/29
- Re: [Gcl-devel] Re: ia64 function descriptors and unexec, Andreas Schwab, 2003/10/29
- Re: [Gcl-devel] Re: ia64 function descriptors and unexec, Peter Chubb, 2003/10/29
- Re: [Gcl-devel] Re: ia64 function descriptors and unexec, Andreas Schwab, 2003/10/29
- Re: [Gcl-devel] Re: ia64 function descriptors and unexec, Stephen J. Turnbull, 2003/10/31
- Re: [Gcl-devel] Re: ia64 function descriptors and unexec, Peter Chubb, 2003/10/31
- Re: [Gcl-devel] Re: ia64 function descriptors and unexec, Richard Stallman, 2003/10/31