From: Michael Snyder <Michael.Snyder@palmsource.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: GDB Patches ML <gdb-patches@sourceware.org>
Subject: Re: Infinite backtrace on (eg.) ARM
Date: Fri, 22 Sep 2006 18:56:00 -0000 [thread overview]
Message-ID: <1158951393.22863.87.camel@localhost.localdomain> (raw)
In-Reply-To: <20060922025908.GA13241@nevyn.them.org>
On Thu, 2006-09-21 at 22:59 -0400, Daniel Jacobowitz wrote:
> On Thu, Sep 21, 2006 at 06:48:44PM -0700, Michael Snyder wrote:
> > So we can check for:
> > * doesn't save its PC, and
> > * frame->level > 0, and
> > * frame->next is not a call dummy.
> >
> > Except that the information "doesn't save its PC" isn't public
> > at the point where we want it. It's hidden within frame_register_unwind
> > and below -- in this case, in trad_frame. So we sort of have a problem
> > of "what do we know, and when do we know it".
> >
> > So -- what if we exported a method to make that info public?
> > It's rather specific, but in this case important: "does this
> > frame save its return address?"
>
> I think this is about the same as what I did in the third URL I sent
> you. I used a slightly roundabout way of answering the same question,
> which didn't require a new interface: if we can tell that the frame is
> deferring the question "where's my PC" to the next frame, then it
> couldn't have saved the PC itself.
>
> The second patch had some points of disagreement, but I think Mark and
> I more or less agreed on the first one before I ran out of time to work
> on it (I'll be back real soon, hopefully next week, to those), and the
> third could probably be gotten into acceptable shape readily once the
> first is in.
OK, I get it.
And actually, the 3rd one works pretty well for me by itself
(with minor tweaking).
Would you be willing to see it go in that way, just to get
something in there to handle the problem? And put the other
parts in at your leisure?
I'll even do it for you. ;-)
Michael
next prev parent reply other threads:[~2006-09-22 18:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-22 1:48 Michael Snyder
2006-09-22 2:59 ` Daniel Jacobowitz
2006-09-22 18:56 ` Michael Snyder [this message]
2006-10-05 21:51 ` Ping, " Michael Snyder
2006-10-05 22:27 ` Daniel Jacobowitz
2006-09-22 19:00 ` Jim Blandy
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=1158951393.22863.87.camel@localhost.localdomain \
--to=michael.snyder@palmsource.com \
--cc=drow@false.org \
--cc=gdb-patches@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