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

Re: gcc-3.3 bugs Debian unstable hppa


Grant Grundler <grundler@parisc-linux.org> 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


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

Reply to: