From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9901 invoked by alias); 30 Nov 2005 01:36:43 -0000 Received: (qmail 9608 invoked by uid 22791); 30 Nov 2005 01:36:42 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.203) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 30 Nov 2005 01:36:40 +0000 Received: by zproxy.gmail.com with SMTP id l1so1362493nzf for ; Tue, 29 Nov 2005 17:36:37 -0800 (PST) Received: by 10.36.18.9 with SMTP id 9mr5214829nzr; Tue, 29 Nov 2005 17:36:37 -0800 (PST) Received: by 10.37.2.35 with HTTP; Tue, 29 Nov 2005 17:36:37 -0800 (PST) Message-ID: <8f2776cb0511291736t50824645pefa5c0db1edcbe49@mail.gmail.com> Date: Wed, 30 Nov 2005 01:38:00 -0000 From: Jim Blandy To: Joel Brobecker , Mark Kettenis , pgilliam@us.ibm.com, gdb@sources.redhat.com Subject: Re: What should be used instead of deprecated_read_memory_nobpt()? In-Reply-To: <20051129221457.GB2238@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200511291401.30945.pgilliam@us.ibm.com> <200511292204.jATM4R1s022362@elgar.sibelius.xs4all.nl> <20051129220752.GQ954@adacore.com> <20051129221457.GB2238@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: 2005-11/txt/msg00629.txt.bz2 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.