CRIS port; frame cleanup crash
Orjan Friberg
orjan.friberg@axis.com
Tue Aug 12 15:11:00 GMT 2003
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
More information about the Gdb-patches
mailing list