This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [CRIS] dwarf2 frame sniffer problem?
On Thu, Mar 11, 2004 at 04:55:04PM +0100, Orjan Friberg wrote:
> I don't know if this is related to the previous suggested problem (i.e.
> the dwarf2 information being wrong), but I changed the test program
> slightly to:
>
> void bar(void) {}
> void foo(void)
> {
> bar();
> }
> int main ()
> {
> foo();
> return 0;
> }
>
> Now foo is no longer a leaf function, and thus saves the return address
> on the stack in its prologue. Stepping over foo ("next" in main) causes
> a breakpoint to be set at the first instruction in foo. After the
> target is stopped at that instruction (which is where the return address
> is pushed on the stack) dwarf2_frame_prev_register is called, which
> thinks that the PC is saved on the stack (case
> DWARF2_FRAME_REG_SAVED_OFFSET) and reads it from there. Obviously the
> value it reads is wrong, since the return address hasn't been pushed yet.
>
> What's wrong here? Is the dwarf2 debug information wrong, or should
> dwarf2_frame_prev_register not have been called while still in the prologue?
The beauty of using the CFI data is that it _is_ supposed to work in
the prologue. It sounds like the CFI is wrong. Could you post both
assembly and CFI data for the same testcase? I don't know CRIS
assembly but I imagine I can interpret it well enough to see what's
going on.
It also sounds like your DWARF2_REG_TO_REGNUM may need work, if the
unwinder thinks r16 is the return address column and GDB thinks it's an
8-bit register.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer