GCJ on mipsel-unknown-linux-gnu

David Daney ddaney@avtrex.com
Fri Apr 16 14:53:00 GMT 2004


Andrew Haley wrote:

> > >  
> > >
> > That is correct.  There are several problems with the current  
> > MD_FALLBACK_FRAME_STATE_FOR.
> > 
> > 1) I think that the current definition of SIGNAL_UNWIND_RETURN_COLUMN 
> > should be changed as I think it currently resides in the slot of a real 
> > register (not sure about this though).
>
>Yeah, I think that's probably true.  I guess it ought not to require a
>special column, but i can't remember the MIPS ABI well enough to know.
>  
>
If all the hard registers had to be preserved, so would be no place for 
the return address, so the pseudo-register column is needed.

I am unclear on how GCC generates code.  If it guarantees that the 
callee-saved registers can be clobbered at the catch point, then one of 
these registers' columns could be used to hold the signal return 
address.  There are two unusable registers (k0, k1) that could probably 
be used also.

There are also several unused columns and one of those could also be 
used to track the return address.

Its current value puts it in $hi's column.  This might be OK, or it 
might not.  I am not sure.

> > 2) It probably does not do the right thing WRT floating point 
> > registers.  But with respect to libgcj, the signal handler does not use 
> > floating point,so it works.
>
>This all depends on how the MIPS ABI uses floating-point registers.
>If they're all callee-saved as they are on some systems, you won't
>have a problem.
>
>Andrew.
>  
>
They are not all callee-saved.  I think the only thing that might allow 
it to work as is, is the fact that the unwinder does not use floating 
point, so the registers magically never get changed.

For the platform I am using, we use software floating point, so the 
hardware floating point registers are never used, so we will never have 
problems WRT this issue.

If it is important to fix these things, I might be persuaded to look 
into it...

David Daney.



More information about the Java mailing list