From: Pedro Alves <pedro@codesourcery.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org
Subject: Re: [unavailable regs/locals, 0/11] Introduction
Date: Wed, 23 Feb 2011 22:49:00 -0000 [thread overview]
Message-ID: <201102232226.20634.pedro@codesourcery.com> (raw)
In-Reply-To: <201102232142.p1NLgx86002352@glazunov.sibelius.xs4all.nl>
On Wednesday 23 February 2011 21:42:59, Mark Kettenis wrote:
> > From: Pedro Alves <pedro@codesourcery.com>
> > Date: Tue, 22 Feb 2011 13:37:58 +0000
> >
> > On Tuesday 22 February 2011 13:27:22, Pedro Alves wrote:
> > > Tested on x86_64-linux, native and gdbserver. No
> > > regressions, and the new tests pass cleanly.
> >
> > ... and it goes without saying:
> >
> > I'd appreciate comments and extra eyeballs on all of this.
> > Pending objections, I'd like to commit after a reasonable wait.
>
> Pedro, I haven't looked very closely at the code yet, but I have a few
> worries. The GCC debug information tends to underspecify the saved
> registers in the unwind info. The unwinder code deals with
> "unspecified"[1] registers by assuming they have the same value as in the
> "inner" frame. How does your new code treat such "unspecified"
> registers?
>
> [1] "unspecified" is different from "undefined"
My changes related to unavailable register values,
as in their register/memory 's contents not having
been collected by a given tracepoint/traceframe. This
is ortogonal from unspecified/undefined in debug info.
There's sort of a run-time vs compile-time distinction.
The unavailable-less I've been talking about is of
the run-time kind. unspecified/undefined is of the
compile-time kind.
If the unwinder assumes an unspecified register has the
same value as in the inner frame, it will continue to do so.
Only when the register value is actually read from the
stack or the register cache, is it determined to be
unavailable/uncollected, and the struct value marked
accordingly. In the unspecified case, if the register
value is available in the next frame (because enough stack
has been collected to cover the next frame, say), it'll
be available in the this frame too. If it's unavailable
in the next frame (because not enough stack had been
collected to cover that particular register, that was
saved last in the stack, say), it'll be unavailable
in the this frame too. (If anything tries to get
at an unavailable value's contents, and exception is
thrown.)
--
Pedro Alves
prev parent reply other threads:[~2011-02-23 22:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-22 13:28 Pedro Alves
2011-02-22 15:54 ` Pedro Alves
2011-02-23 21:52 ` Mark Kettenis
2011-02-23 22:49 ` Pedro Alves [this message]
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=201102232226.20634.pedro@codesourcery.com \
--to=pedro@codesourcery.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