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
next prev parent 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