Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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   ` 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           ` 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           ` 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-12 15:38             ` Orjan Friberg
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

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