Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: sjackman@gmail.com, gdb-patches@sourceware.org
Subject: Re: Fix a crash when stepping and unwinding fails
Date: Tue, 21 Feb 2006 21:03:00 -0000	[thread overview]
Message-ID: <20060221205748.GA31483@nevyn.them.org> (raw)
In-Reply-To: <200602212050.k1LKowmP012208@elgar.sibelius.xs4all.nl>

On Tue, Feb 21, 2006 at 09:50:58PM +0100, Mark Kettenis wrote:
> But if step_frame_id is equal to null_frame_id, we shouldn't be trying
> to insert step-resume-breakpoints.  It means that step_frame_id is
> still uninitialized, since step_frame_id is initialized by:
> 
>   step_frame_id = get_frame_id (get_current_frame ());
> 
> (or equivalent code), and unwinding from sentinel frame shoud always
> yield a frame ID that's different from null_frame_id.

It's this assumption I don't think is right.  I have plenty of
anecdotal evidence from yesterday that it's not right, in fact.
If the prologue analyzer can't handle the code at $pc, then
what do you expect it to put into the frame ID?  Or if it thinks we
are in the outermost frame?

> > That seems like a good change indeed, but probably wouldn't fix this
> > problem.
> > 
> > Hmm, what does frame_pc_unwind do when we've hit the last frame?  I'm
> > not sure it's meaningful.
> 
> How can we hit the last frame?  If we're hitting the last frame, where
> did we come from?
> 
> It may very well be that there are GDB bugs that make step_frame_id
> equal to null_frame_id.  If we can't trace those bugs right now, we
> should probably sprinkle a few gdb_assert()'s around and try to solve
> the issues when we hit those.

We use the null frame ID to represent the outermost frame.  If we can't
find another frame outer to this one, then we assume this one is the
outermost.

Just to sketch out my example a bit more: the embedded OS I'm debugging
lives in ROM.  The application I've supplied to GDB lives in RAM.  In
some later stage of the project, hopefully, I will have GDB magically
load some other ELF files (that I don't have yet) to cover the ROM
code; but right now I can't do that and there's no guarantee I'll have
debug info covering all of it anyway.  So we're executing code way
out in the boondocks.  GDB doesn't have any way on this platform
(ARM Thumb) to guess where the start of a function is if it doesn't
have a symbol table; so it can't be sure that we've really reached the
first instruction of a function, so it has no idea whether $lr is valid
or not.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2006-02-21 20:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-21  4:33 Daniel Jacobowitz
2006-02-21 10:01 ` Eli Zaretskii
2006-02-21 20:28 ` Mark Kettenis
2006-02-21 20:43   ` Daniel Jacobowitz
2006-02-21 20:54     ` Mark Kettenis
2006-02-21 21:03       ` Daniel Jacobowitz [this message]
2006-02-21 21:53         ` Mark Kettenis
2006-02-21 22:59           ` Daniel Jacobowitz
2006-02-22 22:00             ` Mark Kettenis
2006-02-23  2:04               ` Daniel Jacobowitz
2006-02-23 17:04                 ` NZG
2006-05-17 17:59               ` Daniel Jacobowitz
2006-06-13 18:42                 ` Daniel Jacobowitz
2006-06-14 12:33                   ` Joel Brobecker
2006-06-16  1:16                     ` Daniel Jacobowitz
2006-02-22  4:28           ` 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=20060221205748.GA31483@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=sjackman@gmail.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