Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Robert Norton" <rnorton@broadcom.com>
To: gdb@sourceware.org
Subject: Target Dependent Backtrace Termination
Date: Tue, 12 Jun 2007 09:23:00 -0000	[thread overview]
Message-ID: <B0D822BFECD50F4991F2516EA50F273C01B3565A@NT-IRVA-0752.brcm.ad.broadcom.com> (raw)

Hi,
 
Our target specifies in the ABI that frames should form a null
terminated back chain something like:
 
Address     Contents
x:          0 
...           \ Frame of thread's  
y:          x / entry function
...           \ Frame of thread's
z:          y / level 1 function
...
 
So in principal it's not too hard for my target dependent code (i.e.
unwind_this_id) to tell when a backtrace should not proceed any further.
The problem I have is in trying to communicate this to the rest of GDB.
My first approach was to detect when unwind_this_id is passed a
next_frame which is the outermost frame and not return the frame_id in
this case, indicating failure. Unfortunately this caused the backtrace
to go one too far! Looking at some other ports it seems that the
solution is to return the null frame id for the outermost frame thus
causing get_prev_frame_1 to return null and terminating the backtrace.
But this means that the outermost frame doesn't haven't a valid frame
id! Won't this cause problems? Am I missing something rather
fundamental?
 
From what I can see all of the checks on frame validity in
get_prev_frame* are performed on this_frame which, in the case of the
outermost frame, is a valid frame and yet we want it to return null for
the previous frame of the outermost frame. How can this work?  Perhaps I
am confused on the meanings of 'this', 'prev' and 'next' (though I
thought I had this nailed down by now)?
 
Robert

P.S. Sorry if this is a duplicate post, my last one didn't seem to get
through.


             reply	other threads:[~2007-06-12  9:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-12  9:23 Robert Norton [this message]
2007-06-12 11:22 ` Daniel Jacobowitz
2007-06-12 11:57   ` Robert Norton
2007-06-12 12:05     ` Daniel Jacobowitz

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=B0D822BFECD50F4991F2516EA50F273C01B3565A@NT-IRVA-0752.brcm.ad.broadcom.com \
    --to=rnorton@broadcom.com \
    --cc=gdb@sourceware.org \
    /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