From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30029 invoked by alias); 24 Jul 2005 21:26:55 -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 30018 invoked by uid 22791); 24 Jul 2005 21:26:52 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 24 Jul 2005 21:26:52 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1Dwnzl-0003VA-HY; Sun, 24 Jul 2005 17:26:49 -0400 Date: Sun, 24 Jul 2005 21:26:00 -0000 From: Daniel Jacobowitz To: Marcel Moolenaar Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] New port: ia64-*-freebsd Message-ID: <20050724212649.GA13210@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81d1f4d6faa9a09741ad6d68f3c1e5a9@cup.hp.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00176.txt.bz2 On Fri, Jul 15, 2005 at 11:20:46AM -0700, Marcel Moolenaar wrote: > On Jul 14, 2005, at 7:16 PM, Daniel Jacobowitz wrote: > >So, it treats the annex as a memory pointer and returns the contents of > >memory there. Why? And why is this a useful generic implementation? > > Yeah, that's a bit tricky. Here's why: > > The stacked registers that are flushed, live in memory below the > address pointed to by the BSPSTORE register. The stacked registers > that are dirty would be flushed to memory between the values of > BSPSTORE (bottom) and BSP (top) if and when they are being flushed. Unless there isn't room, right? That's where I get confused. How is the data in the core file mapped onto the memory space? > I figured that from an API point of view it's safer to access the > dirty registers by their index or offset relative to BSPSTORE, and > not by their absolute memory address, because their corresponding > memory address is unreal. I can change the backing store pointer > (i.e. BSPSTORE) and then flush the dirty registers. So, tying the > dirty registers to their would-be memory address seemed "wrong". > Hence, the offset is the offset relative to BSPSTORE. Sure... though documentation of this would be good. > However when the dirty registers need to be accessed as if they > were flushed, as needs to be done on Linux, then we need to know > to value of BSPSTORE so that we can map the relative offset to > an absolute memory location. For this reason I use the annex. > To support cross-debugging when gdb runs on a 32-bit host, I > cannot pass BSPSTORE by value (sizeof(void*) < sizeof(CORE_ADDR)). > So, I pass it by reference. Hence the indirection. This does not seem like anything that needs or wants a generic implementation. I think we will need to arrange for the target to override and augment the core file operations, so that this can be in an ia64-specific file - probably, an ia64-linux or ia64-freebsd (it's not clear to me which from your description) specific file. > There's just one slight problem: the number of dirty registers is > variable, but bounded. Unfortunately the upper bound is rather > high: 16383. This yields a worse-case memory footprint of 128KB :-/ > (8 bytes per register and NaT collection). > I think that on average the number of dirty registers is something > like 128. I doesn't really look like a good idea to create the 128KB > of memory for the worst-case when 1KB would be sufficient on > avarage. This I know how to handle; it hasn't been implemented yet, but the optional/target-available registers interface will allow you to create the necessary number of dirty registers in the regcache. I'm not sure I agree that they belong there, but I don't know enough about it to judge. > >>From your description abov it sounds like these ought to be in their > >own core file note anyway; why have they ended up in "memory"? > > That's currently how Linux works and it's also currently how FreeBSD > creates the core files. Linux cannot do it any other way, because it's > all abstracted by the kernel on live processes and if gdb doesn't know > the difference between flushed and dirty stacked registers, you cannot > dump the dirty stacked registers to a core file anywhere else then where > they would be when they were flushed. > > On FreeBSD the note isn't yet created because that requires a bit of > work and we had the plans to revamp the core file notes anyway (due > to threading). So, I decided to first get the port contributed and > then work on how best to deal with the dirty stacked registers. This > then could be part of a larger (cross-platform) revamp of how FreeBSD > creates core files, which would also result in a rather large set of > changes to binutils. > > Anyway: since some targets work with the abstraction, there need to > be a couple places where accessing dirty registers need to be mapped > to memory references. This may change in the future. Except FreeBSD, it sounds like, supports cases where they couldn't be mapped unambiguously to memory. I really recommend fixing your notes first and not making GDB support this scheme. Anyway, that's enough out of me. I'll leave the rest to Mark and the ia64 maintainers. -- Daniel Jacobowitz CodeSourcery, LLC