Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: NZG <ngustavson@emacinc.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org
Subject: Re: frame theory, was pointer madness
Date: Thu, 26 Jan 2006 21:54:00 -0000	[thread overview]
Message-ID: <200601261552.46222.ngustavson@emacinc.com> (raw)
In-Reply-To: <200601262121.k0QLLGfw017308@elgar.sibelius.xs4all.nl>

> > prev->frame->next
> >
> > NULL->3->2->1->0->-1->-1->-1........
>
> I get the feeling that you've got a wrong picture.  I'd view things
> as:
>
> -1 -> 0 -> 1 -> 2 -> 3 -> NULL
Is this with respect the to legend above(prev->frame->next)?
Bacause that would imply that the ->next frame after 0 is 1, but it's not, 
it's -1 correct?

prev decrements the level next increments it.

It's far easier for me to imply next with ->
and previous with <-
This seems more natural. 

> Sorry but what you say here doesn't make any sense to me.  GDB unwinds
> the stack from the registers values that are currently found in the
> cpu.
And from cached values of it's read registers. In my case I suspect the 
problem is that the regcache is being shown as initialized when it in fact is 
not. It does not read the registers on every access.

> Unwinding involves interpreting debug info or analyzing code to 
> determine where the register values for the previous frames are
> stored.  This process can terminate (i.e. if we hit main, or if the
> value for the frame pointer register for a frame is zero[1]) but isn't
> guaranteed to.  Actually the unwinding process is difficult to get
> completely right, and might send us off into the wrong direction,
> resulting in rubish frames.
In my case it goes into an infinite loop and continually prints rubbish frames 
to the screen.

> I'm not sure what your problem is, only that GDB seems to work pretty
> well on OpenBSD/mac68k, so I doubt there is a fundamental problem in
> the generic m68k unwinder code.
Well that depends on what you mean by "generic".
This is being applied to remotely debug a Coldfire core which I suspect has 
some differences from your machine.
If it only works on your machine and not mine, then it has failed to be 
"generic".

Also note that this is a very specific crash that only happens when you try to 
unwind the frames after connecting to a remote target before beginning 
execution. Have you attempted to do that?

NZG


  reply	other threads:[~2006-01-26 21:54 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-23 20:39 gdb code review, " NZG
2006-01-23 20:48 ` Daniel Jacobowitz
2006-01-23 20:51 ` Jim Blandy
2006-01-24 17:19   ` NZG
2006-01-24 19:29     ` NZG
2006-01-24 21:27       ` Jim Blandy
2006-01-24 21:58         ` NZG
2006-01-24 22:11           ` Daniel Jacobowitz
2006-01-25  0:01           ` Jim Blandy
2006-01-25  4:41             ` Eli Zaretskii
2006-01-25  4:59               ` Jim Blandy
2006-01-25  5:25                 ` Jim Blandy
2006-01-25 17:21                   ` Eli Zaretskii
2006-01-25 18:49                     ` Jim Blandy
2006-01-25 19:58                       ` Eli Zaretskii
2006-01-25 17:15                 ` Eli Zaretskii
2006-01-26 16:19             ` NZG
2006-01-26 16:43               ` Daniel Jacobowitz
2006-01-26 19:55                 ` frame theory, was " NZG
2006-01-26 19:59                   ` Daniel Jacobowitz
2006-01-26 20:17                     ` NZG
2006-01-26 20:22                       ` Daniel Jacobowitz
2006-01-26 21:21                   ` Mark Kettenis
2006-01-26 21:54                     ` NZG [this message]
2006-01-26 22:40                       ` Mark Kettenis
2006-01-26 22:44                         ` Daniel Jacobowitz
2006-01-26 23:27                           ` remote connection crash, was frame theory NZG
2006-01-26 23:32                             ` Daniel Jacobowitz
2006-01-26 23:42                             ` Jim Blandy
2006-01-26 23:45                               ` Daniel Jacobowitz
2006-01-26 23:57                                 ` Jim Blandy
2006-01-27  0:04                                   ` NZG
2006-01-30 17:02                                     ` 5282 gdb Eclipse MI support, was remote connection crash NZG
2006-01-26 23:47                           ` frame theory, was pointer madness Accounts
2006-01-26 23:16                   ` Jim Blandy
2006-01-26 23:39                     ` Jim Blandy
2006-01-27  7:19                     ` Eli Zaretskii

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=200601261552.46222.ngustavson@emacinc.com \
    --to=ngustavson@emacinc.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    /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