Re: CRIS port; frame cleanup crash

[Orjan Friberg <orjan.friberg@axis.com>]

Orjan Friberg wrote:
> After a long overdue update of my gdb cvs tree, I found that something 
> broke late March/early April.  I don't quite understand what goes on, 
> but it seems to happen the first time a frame allocated by 
> deprecated_frame_xmalloc_with_cleanup is freed by do_cleanups (which 
> happens in cris_skip_prologue_main).  gdb segfaults on a call to free 
> with a pointer to that frame.

I hacked around that particular failure by not allocating a frame, and 
simply relying on symbol information.  With that out of the way, I'm 
able to run the testsuite, albeit with some more FAILs than stock a gdb 5.3.

However, poking around in all the stuff that has been deprecated, I'm 
sort of at a loss as to where to start.  Replacing the deprecated 
function/macros one at a time doesn't look feasible, since a lot of 
functionality is replaced by the same functions 
(push_dummy_code/push_dummy_call for example).  Is there a preferred way 
of doing it, or is it just a matter of diving right into it?  I'd prefer 
to do it in a structured way to be able to catch when things start to 
break.  I see there are a couple of targets that have made the 
transition (d10v and m68hc11 for example), so that should provide some help.

Also, is there any documentation for the frame handling machinery that I 
didn't find?  I checked the archives, and read a bunch of Andrew 
Cagney's posts related to this, but couldn't really get the big picture 
from that.  (The Internals manual has only a brief mention of frames in 
section 3.1.)

Thanks for any help.

-- 
Orjan Friberg
Axis Communications