Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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