From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8445 invoked by alias); 30 Nov 2005 17:51:07 -0000 Received: (qmail 8431 invoked by uid 22791); 30 Nov 2005 17:51:06 -0000 X-Spam-Check-By: sourceware.org Received: from e36.co.us.ibm.com (HELO e36.co.us.ibm.com) (32.97.110.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Nov 2005 17:50:59 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id jAUHovr7029812 for ; Wed, 30 Nov 2005 12:50:57 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id jAUHqQGD062256 for ; Wed, 30 Nov 2005 10:52:26 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id jAUHouMA004982 for ; Wed, 30 Nov 2005 10:50:57 -0700 Received: from dyn9047022123-009047022095.beaverton.ibm.com (dyn9047022123-009047022095.beaverton.ibm.com [9.47.22.95]) by d03av01.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id jAUHouZf004959; Wed, 30 Nov 2005 10:50:56 -0700 From: Paul Gilliam Reply-To: pgilliam@us.ibm.com To: Jim Blandy Subject: Re: What should be used instead of deprecated_read_memory_nobpt()? Date: Wed, 30 Nov 2005 23:17:00 -0000 User-Agent: KMail/1.6.2 Cc: Joel Brobecker , Mark Kettenis , Michael Synder , gdb@sources.redhat.com References: <200511291401.30945.pgilliam@us.ibm.com> <20051129221457.GB2238@nevyn.them.org> <8f2776cb0511291736t50824645pefa5c0db1edcbe49@mail.gmail.com> In-Reply-To: <8f2776cb0511291736t50824645pefa5c0db1edcbe49@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200511301021.32626.pgilliam@us.ibm.com> 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: 2005-11/txt/msg00639.txt.bz2 Way Cool. Thanks for the background. Maybe someone can pick up the tourch for this. I wonder how this fits in with Michael Snyder's multi-process gdb? http://sourceware.org/ml/gdb-patches/2005-11/msg00490.html -=# Paul #=- On Tuesday 29 November 2005 17:36, Jim Blandy wrote: > Some background: > > The long-term plan here was to have GDB pass frame objects around > everywhere, and always fetch registers and memory relative to a > specific frame. It's pretty obvious why you need to have a frame to > find a register value, but why you'd want to read memory "from a > frame" is less so. > > The idea was to use frames to reduce GDB's dependence on global state: > - A frame has a specific architecture. > - A frame belongs to a specific thread. > - Since threads belong to specific processes, a frame belongs to a > specific process, too, which would help with debugging multi-address > space programs. > > So if you have a frame around to provide context for whatever you're > trying to do, you don't have to depend on a global arch object, a > global current thread, a global process, and so on. > > This was Andrew Cagney's initiative, but he's not active on GDB any > more, which is why I say "the idea was to..." I think it's a good > approach, as far as it goes, and I hope we carry it on. We should use > the frame-based register and memory operations whenever possible; > where you don't have a frame, try to figure out how to propage an > appropriate frame out to where it's needed; go ahead and add 'frame' > parameters to functions where it makes sense. > > There are some cases where it doesn't make sense. For example, our > 'struct value' objects read memory lazily, so if you were going to use > frames for everything, you'd need to have the value point to the frame > GDB should use to read the value's contents when they're actually > needed. But values persist across continues and steps, whereas frame > objects are destroyed and rebuilt each time the inferior runs. So > values can't just point to frames. Frame ID's are more persistent, > but they're still not right, because the frame might really be popped > in the inferior. > > I think this shows that, to really acheive the dream, we also need an > object representing an address space. Memory reads and writes would > accept an address space argument. A thread would have a (current?) > address space, and thus a "frame's address space" would be the > "frame's thread's address space". values would contain an address > space to use to fetch their values when needed. > >