gcl-devel
[Top][All Lists]
Advanced

[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




reply via email to

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