This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Debug info detection.
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Michal Ludvig <mludvig at suse dot cz>
- Cc: GDB Patches <gdb-patches at sources dot redhat dot com>
- Date: Fri, 07 Mar 2003 10:25:50 -0500
- Subject: Re: [RFA] Debug info detection.
- References: <3E67D471.3040100@suse.cz>
Hi all,
The attached patch adds new function cfi_have_unwind_info() that I'll use for detection, whether a given function has a dwarf2 unwind info (from .eh_frame or .debug_frame) or not. I'll use it in the upcomming x86_64_frame_p() to detect which set of unwind functions should be returned for a given frame.
Your comment about x86_64_frame_p() makes me wonder if you're going in
the right direction.
Looking at the d10v, you'll see:
frame_unwind_append_predicate (gdbarch, d10v_frame_p);
For the x86-64, since it wants to also use dwarf2cfi and dwarf2eh, I'd
expect to see something like:
/* Try for a true CFI frame first. If that fails, fall back to
a .eh_frame info. */
frame_unwind_append_predicate (gdbarch, dwarf2cfi_frame_p);
frame_unwind_append_predicate (gdbarch, dwarf2eh_frame_p);
/* Finally, and as a last resort, use a prologue based unwinder. */
frame_unwind_append_predicate (gdbarch, x86_64_frame_p);
While I'm sure that splitting dwarf2cfi and dwarf2eh is logical, having
separate x86_64_frame_p() that only implements traditional prologe based
unwind is correct.
Can I suggest starting from the other end - a new file
dwarf2cfi-frame.[hc] and then moving in from there? The dwarf2expr.[hc]
code was recently added and that was ment to superseed much of dwarf2cfi.c.
I'd also have a copy of cagney_offbyone-20030303-branch handy (you could
even prototype the changes on it or a successor). That contains a key
fix that hasn't yet been committed to the mainline.
Andrew