This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: CRIS port; frame cleanup crash
- From: Orjan Friberg <orjan dot friberg at axis dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Tue, 12 Aug 2003 17:11:19 +0200
- Subject: Re: CRIS port; frame cleanup crash
- Organization: Axis Communications
- References: <3F379A74.4080508@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