From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11334 invoked by alias); 25 Jul 2005 17:36:49 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10810 invoked by uid 22791); 25 Jul 2005 17:36:29 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 25 Jul 2005 17:36:29 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1Dx6rh-0002vD-Ih; Mon, 25 Jul 2005 13:35:45 -0400 Date: Mon, 25 Jul 2005 17:36:00 -0000 From: Daniel Jacobowitz To: Marcel Moolenaar Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] New port: ia64-*-freebsd Message-ID: <20050725173545.GA11163@nevyn.them.org> Mail-Followup-To: Marcel Moolenaar , gdb-patches@sources.redhat.com References: <20050705195104.GA1584@ns1.xcllnt.net> <20050715000144.GB21620@nevyn.them.org> <2845064d598c2c3d2433909ea136f830@cup.hp.com> <20050715021634.GA27723@nevyn.them.org> <81d1f4d6faa9a09741ad6d68f3c1e5a9@cup.hp.com> <20050724212649.GA13210@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00190.txt.bz2 On Mon, Jul 25, 2005 at 10:32:27AM -0700, Marcel Moolenaar wrote: > > That's where I get confused. How is > >the data in the core file mapped onto the memory space? > > I'm not quite sure I get your drift. Let me just answer what I think > you mean: > > The backing store is nothing more than a second stack. The first being > the well-known memory stack onto which (stacked) local variables live. > The backing store grows upwards and the memory stack grows downwards. > So, in essence, it's a mmap'd region. Either created by the kernel when > the process is created, or created by the threading implementation. > In the core file the backing store is part of some loadable segment. > Either by itself or part of a larger block of memory. No, that's not what I mean. Here and further below you think I'm talking about the concept of the target object. I'm not. I'm talking specifically about the corefile implementation you included. That implementation reads from an address in memory to find the registers. If there's no room for them in memory, where the heck are they, and how can you find them by reading from memory? > >I really recommend fixing your notes first and not making GDB support > >this scheme. > > I've thought about it. The point is that GDB already needs to support it > for Linux, so splitting up the work in such a way that FreeBSD > temporarily > has the same "limitations" as Linux seemed ideal. Not only is it > possible > to improve the overall core file support in FreeBSD, it also allows > Linux > to move away from the abstraction. In that sense, the abstraction is > gradually moved out of GDB. And as for any interim solution: there is > bound > to be some icky code for a while. So the answer to my above question is "you can't yet"? > All I can say is that I'll think about it: The FreeBSD release schedule > is > now in my advantage, but getting binutils to grok a whole new kind of > core > notes may by itself turn out to be... euh... challenging... :-) Actually it's quite easy. -- Daniel Jacobowitz CodeSourcery, LLC