[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: gcc-3.3 bugs Debian unstable hppa
From: |
Camm Maguire |
Subject: |
[Gcl-devel] Re: gcc-3.3 bugs Debian unstable hppa |
Date: |
09 Mar 2004 18:36:40 -0500 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Greetings!
Grant Grundler <address@hidden> writes:
> On Mon, Mar 08, 2004 at 05:58:37PM -0500, Camm Maguire wrote:
> > Is it possible there was a change in setjmp function on hppa, in say
> > the last two years (i.e. that would effect this)? Lamont provided the
> > assembler and described the setjmp failure at the time, but I cannot
> > remember the details now.
>
> Mail archive might help: http://lists.parisc-linux.org/
>
> Here's at least one thread on setjmp when the details
> where being worked:
> http://lists.parisc-linux.org/pipermail/parisc-linux/2001-May/012459.html
>
Thanks!
> > I think we need the contents of all registers capable of holding a
> > machine word length pointer on the stack at this point in the code.
> > It is not important (so much) if unnecessary data is copied on the
> > stack, but rather critical that no C variable in a stack frame higher
> > up which could hold a pointer be left in a register with no copy on
> > the stack. This does not have to do with function calling per se.
>
> Doesn't setjmp/longjump just save enough context to resume execution?
> By definition, saving the register state and current stack should
> be sufficient to do anything.
> Can any code determine which registers represent a particular
> local/stack variable and where it's stored on the stack?
> I'd think only gcc can do that.
> What if GCC decides a local variable doesn't need stack space reserved
> and only allocates a register for the code?
>
I don't think such register identification is possible in C/asm. This
is why a "conservative" garbage collection scheme requires copying all
registers possibly containing local pointers to the stack and marking
them before sweeping unused memory.
> > I probably ought to mention that we also put in special code for ia64,
> > but this was to make sure to walk *both* its stacks. I'm assuming
> > hppa has only one.
>
> yup
>
> > We also have a NULL_OR_ON_C_STACK macro which in hppa's case
> > identifies a pointer as being on the C stack if (long)ptr<0. This
> > appears to be correct.
> >
> > Please keep in mind that this problem is hppa specific, so it pretty
> > much must be in an hppa-specific define or asm, or in gcc.
>
> yeah...hopefully carlos/jda can help you out.
>
Thanks again!
Take care,
>
> hth,
> grant
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah