GCJ on mipsel-unknown-linux-gnu

Fri Apr 16 18:02:00 GMT 2004

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.