This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch] Dwarf2 virtual frame pointer
- From: Mark Kettenis <kettenis at gnu dot org>
- To: nathan at codesourcery dot com
- Cc: gdb-patches at sources dot redhat dot com, paul at codesourcery dot com
- Date: Fri, 11 Feb 2005 22:12:28 -0500 (EST)
- Subject: Re: [patch] Dwarf2 virtual frame pointer
- References: <420B2F90.4060403@codesourcery.com>
From: Nathan Sidwell <nathan@codesourcery.com>
Date: Thu, 10 Feb 2005 09:55:28 +0000
Hi,
The default frame pointer accessor only copes with a fixed frame pointer.
I've added a dwarf2_virtual_frame_pointer function, which can be enabled
with
set_gdbarch_virtual_frame_pointer (gdbarch, dwarf2_virtual_frame_pointer)
It executes the cfa for the supplied PC and determines which register
is the frame pointer at that point. I've not hooked it into any
existing architectures, but verified its functionality on an unrealeased
architecture where $sp or $fp might be the relevent register.
I've tested on i686-pc-linux-gnu also, ok?
Almost certainly no. Replacing `struct frame *next_frame' with
`CORE_ADDR pc' is moving backward instead of forward. Any functions
that starts with legacy_ should not be used in generic code like the
code in dwarf2-frame.c.
Can you explains what you're trying to accomplish?
If you're trying to use the DWARF CFI for anything else than unwinding
the stack, like finding out whether the location of local variables is
relative to $sp or $fp then rethink your strategy. This is not what
the DWARF CFI is for.
Mark