From: Yao Qi <yao@codesourcery.com>
To: Tom Tromey <tromey@redhat.com>
Cc: <gdb-patches@sourceware.org>
Subject: Re: [RFC] MI notification on register changes
Date: Mon, 05 Nov 2012 10:26:00 -0000 [thread overview]
Message-ID: <5097941F.8080604@codesourcery.com> (raw)
In-Reply-To: <87zk30ot22.fsf@fleche.redhat.com>
On 11/03/2012 12:42 AM, Tom Tromey wrote:
> First, Yao sees that lval_memory on x86, but I don't see it on x86-64.
> I wonder whether it is a bug elsewhere.
>
Tom,
I also see lval_memory on x86-64, and I am a little surprised that you
see lval_register.
(gdb) b middle
Breakpoint 1 at 0x40056d
(gdb) run
Starting program: gdb/testsuite/gdb.base/nodebug
Breakpoint 1, 0x000000000040056d in middle ()
(gdb) up
#1 0x000000000040059d in top ()
(gdb) p/x $rbp
$1 = 0x7fffffffe5a0
(gdb) set $rbp=0x7fffffffe5a0
Breakpoint 1, value_assign (toval=0xdaf7a0, fromval=0xe36170) at
../../gdb/gdb/valops.c:1246
1246 switch (VALUE_LVAL (toval))
top>p toval->lval
$1 = lval_memory
and I think it is reasonable to see 'lval_memory' instead of
'lval_register' here. When executing this 'set' command, the callchain
looks like,
evaluate_subexp_standard
|
' case OP_REGISTER: value_of_register
In value_of_register,
frame_register (frame, regnum, &optim, &unavail,
&lval, &addr, &realnum, raw_buffer);
....
VALUE_LVAL (reg_val) = lval;
The 'lval' can be set to 'lval_register' or 'lval_memory' in
frame_register. So I don't see anything wrong here.
> Second, Pedro pointed out this PR:
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=7574
>
> ... which seems apropos. It seems that the best thing is a generic
> "target changed" notification for the reasons mentioned there.
'target changed' observer and 'register changed' observer serves
differently. 'target changed' observer is mostly for keeping gdb
internal states, such as regcache and frames, consistent, however,
'register changed' observer is for external notifications.
AFAICS, the reason 'target changed' observer is not replaced by 'memory
changed' observer and 'register change' observer is that GDB doesn't
know the side effect of setting a register or a piece of memory, so GDB
conservatively uses 'target changed' observer.
--
Yao
next prev parent reply other threads:[~2012-11-05 10:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 7:24 Yao Qi
2012-11-01 0:36 ` ping: " Yao Qi
2012-11-01 20:48 ` Tom Tromey
2012-11-02 9:56 ` Yao Qi
2012-11-02 16:42 ` Tom Tromey
2012-11-05 10:26 ` Yao Qi [this message]
2012-11-05 20:10 ` Tom Tromey
2012-11-06 6:05 ` Yao Qi
2012-11-06 20:00 ` André Pönitz
2012-11-07 15:35 ` Marc Khouzam
2012-11-07 17:01 ` Pedro Alves
2012-11-07 18:18 ` Marc Khouzam
2012-11-07 18:54 ` Tom Tromey
2012-11-07 21:09 ` André Pönitz
2012-11-09 1:47 ` Yao Qi
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=5097941F.8080604@codesourcery.com \
--to=yao@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=tromey@redhat.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