Re: GCJ on mipsel-unknown-linux-gnu

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > 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.

I wouldn't have thought $hi a good choice.

Can't you just use DWARF_FRAME_RETURN_COLUMN ?  That's either the PC
if the PC is a visible register or the last hard register+1 if it's
not.

 > > > 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.
 >
 > 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.

That's reasonable.  Trouble is, some library calls might use fp
internally.

 > 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...

It would be very nice to get this stuff checked in.

RTH, you listening?  Is DWARF_FRAME_RETURN_COLUMN ok?

Andrew.