From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17121 invoked by alias); 5 Nov 2012 10:26:05 -0000 Received: (qmail 17109 invoked by uid 22791); 5 Nov 2012 10:26:04 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_EG X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Nov 2012 10:25:56 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1TVJsR-0006eF-I0 from Yao_Qi@mentor.com ; Mon, 05 Nov 2012 02:25:55 -0800 Received: from SVR-ORW-FEM-04.mgc.mentorg.com ([147.34.97.41]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Nov 2012 02:25:55 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.1.289.1; Mon, 5 Nov 2012 02:25:53 -0800 Message-ID: <5097941F.8080604@codesourcery.com> Date: Mon, 05 Nov 2012 10:26:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Tom Tromey CC: Subject: Re: [RFC] MI notification on register changes References: <1350977008-28632-1-git-send-email-yao@codesourcery.com> <87lielqcba.fsf@fleche.redhat.com> <509398D8.7060104@codesourcery.com> <87zk30ot22.fsf@fleche.redhat.com> In-Reply-To: <87zk30ot22.fsf@fleche.redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00079.txt.bz2 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