From: Orjan Friberg <orjan.friberg@axis.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [CRIS] dwarf2 frame sniffer problem?
Date: Fri, 19 Mar 2004 00:09:00 -0000 [thread overview]
Message-ID: <405072FE.1010403@axis.com> (raw)
In-Reply-To: <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
WARNING: multiple messages have this Message-ID
From: Orjan Friberg <orjan.friberg@axis.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [CRIS] dwarf2 frame sniffer problem?
Date: Thu, 11 Mar 2004 14:09:00 -0000 [thread overview]
Message-ID: <405072FE.1010403@axis.com> (raw)
Message-ID: <20040311140900.bFpZYXDjVvLXIHMoLA6DAjEBBS5VsUliKM9KPKKl4V4@z> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2004-03-11 14:09 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-10 16:53 Orjan Friberg
2004-03-10 16:59 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Orjan Friberg [this message]
2004-03-11 14:09 ` Orjan Friberg
2004-03-11 15:55 ` Orjan Friberg
2004-03-11 17:05 ` Andrew Cagney
2004-03-19 0:09 ` Andrew Cagney
2004-03-19 0:09 ` Orjan Friberg
2004-03-12 12:00 ` Orjan Friberg
2004-03-11 17:11 ` Daniel Jacobowitz
2004-03-12 10:23 ` Orjan Friberg
2004-03-19 0:09 ` Orjan Friberg
2004-03-12 15:38 ` Orjan Friberg
2004-03-19 0:09 ` Orjan Friberg
2004-03-12 13:50 ` Orjan Friberg
2004-03-19 0:09 ` Orjan Friberg
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-12 15:38 ` Daniel Jacobowitz
2004-03-15 10:19 ` Orjan Friberg
2004-03-19 0:09 ` Orjan Friberg
2004-03-16 16:26 ` Orjan Friberg
2004-03-16 19:13 ` Daniel Jacobowitz
2004-03-16 20:51 ` Hans-Peter Nilsson
2004-03-16 22:27 ` Daniel Jacobowitz
2004-03-16 23:38 ` Hans-Peter Nilsson
2004-03-16 23:58 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Hans-Peter Nilsson
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Hans-Peter Nilsson
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Orjan Friberg
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-19 0:09 ` Orjan Friberg
2004-03-19 0:09 ` Orjan Friberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=405072FE.1010403@axis.com \
--to=orjan.friberg@axis.com \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox