This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [CRIS] dwarf2 frame sniffer problem?
- From: Orjan Friberg <orjan dot friberg at axis dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 11 Mar 2004 15:09:02 +0100
- Subject: Re: [CRIS] dwarf2 frame sniffer problem?
- Organization: Axis Communications
- References: <404F481E.9060709@axis.com> <20040310165905.GA4291@nevyn.them.org>
Daniel Jacobowitz wrote:
Well, it sounds like the return address is being unwound incorrectly.
You may want to take a look at the CFI data by hand, and then compare
with dwarf2_frame_prev_register. I can't quite imagine how you'd get
the one-instruction-early behavior, though :)
(The "one-instruction-early" description of the breakpoint setting was
incorrect - that breakpoint was actually the "break main" breakpoint.
Thanks for noticing.)
The test program is just:
void foo(void) {}
int main ()
{
foo();
return 0;
}
Here's what happens when I do "next" over the call to foo():
dwarf2_frame_prev_register gets called for register 15 (PC). The switch
on cache->reg[regnum].how leads to DWARF2_FRAME_REG_SAVED_REG, where
cache->reg[regnum].loc.reg says the PC is located in register 16, so we
unwind register 16 from the next frame, which is definitely wrong
(register 16 is a 8-bit zero register). Changing 16 to 27 (SRP, where
the PC is saved) makes "next" work in this simple case.
I did a readelf -w on the binary (below), and looked at the
.debug_frame-section (hoping that's what you meant by "look at the CFI
data by hand"), and though my understanding of this is limited I get the
impression that the dwarf2 CFI for CRIS is wrong (but that the dwarf2
frame unwinder does the right thing). "Return address column" says 16,
and for main (where the SRP is pushed on the stack) it says
"DW_CFA_offset: r16 at cfa-4".
I checked section 6.4.1 in the dwarf2 standard, but I couldn't confirm
my suspicions since some of the fields mentioned weren't present in the
readelf output (return_address_register for example).
00000010 0000000c ffffffff CIE
Version: 1
Augmentation: ""
Code alignment factor: 1
Data alignment factor: -1
Return address column: 16
DW_CFA_def_cfa: r14 ofs 0
00000020 00000014 00000010 FDE cie=00000010 pc=000802e4..000802f0
DW_CFA_advance_loc: 0 to 000802e4
DW_CFA_def_cfa: r8 ofs 4
DW_CFA_offset: r8 at cfa-4
DW_CFA_nop
DW_CFA_nop
00000038 00000014 00000010 FDE cie=00000010 pc=000802f0..0008030a
DW_CFA_advance_loc: 0 to 000802f0
DW_CFA_def_cfa: r8 ofs 8
DW_CFA_offset: r16 at cfa-4
DW_CFA_offset: r8 at cfa-8
--
Orjan Friberg
Axis Communications