From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9548 invoked by alias); 20 Apr 2006 19:03:10 -0000 Received: (qmail 9538 invoked by uid 22791); 20 Apr 2006 19:03:09 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 20 Apr 2006 19:03:08 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-9-6.inter.net.il [80.230.9.6]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id EAA53284 (AUTH halo1); Thu, 20 Apr 2006 22:03:04 +0300 (IDT) Date: Fri, 21 Apr 2006 11:45:00 -0000 Message-Id: From: Eli Zaretskii To: gdb@sourceware.org In-reply-to: <20060420184153.GA21153@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 20 Apr 2006 14:41:53 -0400) Subject: Re: Checking if addess is on stack? Reply-to: Eli Zaretskii References: <200604201426.59360.ghost@cs.msu.su> <200604201548.36899.ghost@cs.msu.su> <20060420124903.GA11015@nevyn.them.org> <20060420143944.GA14255@nevyn.them.org> <20060420184153.GA21153@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00284.txt.bz2 > Date: Thu, 20 Apr 2006 14:41:53 -0400 > From: Daniel Jacobowitz > > > > print &ptr->i > > > watch *$31 > > > (Where $31 is the right number. > > > > But "watch ptr->i" already does that for you. Except that it _also_ > > watches &ptr, and that latter address is what goes out of scope when > > we leave func2. > > These two are not at all the same. Suppose ptr is being walked along a > linked list. The user might be interested in the expression "ptr->i", > but in my experience that's almost never what I want if ptr is moving; > instead, I am interested in (for example) something scribbling over > this particular element of the linked list. I don't care when ptr goes > out of scope, or when ptr is changed. I'm interested in the memory. That's one possible situation, sure. But there are others: someone could be scribbling over ptr->i by inadvertently changing ptr itself. If you think this latter situation is unlikely or uninteresting, you in effect say that our whole concept of watching expression values is wrong. > > So perhaps we need to modify the watchpoint machinery so that when > > func2 returns, we stop watching the parts of the expression that are > > popped from the stack, but continue watching those which are still > > valid and in scope. Would that make sense? > > I don't understand. How could we continue watching anything, if we can > no longer evaluate the expression? None of the expression is still in > scope. But this particular expression's result is just an address, and that address can be watched without recomputing the expression. > > I think it can be achieved with setting 2 watchpoints: one on > > "ptr->i", the other on the address it points to. > > That will catch when ptr goes out of scope, but we don't care about > that. In my example, ptr goes out of scope in one function, but the > thing it points to doesn't go "out of scope" until much later. In your example, you (the user) knew what you were after. I was arguing that doing this always in a front end, like what Vladimir was suggesting, might not be what users expect in each particular case.