From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4319 invoked by alias); 27 Apr 2006 00:53:37 -0000 Received: (qmail 4102 invoked by uid 22791); 27 Apr 2006 00:53:37 -0000 X-Spam-Check-By: sourceware.org Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Apr 2006 00:53:34 +0000 Received: by xproxy.gmail.com with SMTP id h29so1057074wxd for ; Wed, 26 Apr 2006 17:53:33 -0700 (PDT) Received: by 10.70.70.5 with SMTP id s5mr134553wxa; Wed, 26 Apr 2006 17:53:33 -0700 (PDT) Received: by 10.70.129.13 with HTTP; Wed, 26 Apr 2006 17:53:33 -0700 (PDT) Message-ID: <8f2776cb0604261753p1cfe60d7qd3972811e210a426@mail.gmail.com> Date: Thu, 27 Apr 2006 00:53:00 -0000 From: "Jim Blandy" To: "Joel Brobecker" , gdb-patches@sources.redhat.com Subject: Re: [RFC] problem fetching inferior memory due to breakpoint In-Reply-To: <20060426191946.GA28844@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060426190517.GA930@adacore.com> <20060426191946.GA28844@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00355.txt.bz2 On 4/26/06, Daniel Jacobowitz wrote: > Try safe_frame_unwind_memory, the other caller of > deprecated_read_memory_nobpt. Many other prologue analyzers already > seem to use that. Prologue analyzers get called in two contexts, though: from the skip_prologue gdbarch method, and from the frame unwinding stuff. In the former case, there's no frame at hand to use; there may not even be a program running, if the user is setting breakpoints before doing a 'run'. I'm happy to pass a frame to my analyzer, use safe_frame_unwind_memory when it's non-null, and target_read_memory when it's null, but this seems klunky. The whole reason safe_frame_unwind_memory takes a frame argument at all is that, in the future (at present it ignores its frame argument) the frame will identify which process/address space to read. But using frames for this isn't good enough, because, as skip_prologue shows, we also need to be able to read memory when there are no frames present. Some of this was discussed here: http://sourceware.org/ml/gdb/2005-11/msg00628.html Ideally, the arch's skip_prologue function would take, in addition to a CORE_ADDR, one of my imaginary address space objects. Or, CORE_ADDR would become a struct carrying an address space object and an offset within that address space. Then the CORE_ADDR alone would be enough to do the read. You could have address space objects representing the memory loaded by a shared library, or sections of a relocatable object, as well as live processes' address spaces. If GDB were written in C++, we could overload +, -, etc. on CORE_ADDR and write trim source for bloated object code... but my floor time is up, and I defer to my esteemed (and more practical-minded) colleagues.