Re: gcc-3.3 bugs Debian unstable hppa
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 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.
hth,
grant
Reply to: