From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9080 invoked by alias); 25 Jul 2005 17:32:42 -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 9051 invoked by uid 22791); 25 Jul 2005 17:32:31 -0000 Received: from palrel13.hp.com (HELO palrel13.hp.com) (156.153.255.238) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 25 Jul 2005 17:32:31 +0000 Received: from cllmail.cup.hp.com (cllmail.cup.hp.com [15.244.92.83]) by palrel13.hp.com (Postfix) with ESMTP id 11B711C06E45; Mon, 25 Jul 2005 10:32:29 -0700 (PDT) Received: from [15.244.95.35] (powerbook.americas.hpqcorp.net [15.244.95.35]) by cllmail.cup.hp.com (8.9.3 (PHNE_29774)/8.9.3 SMKit7.04) with ESMTP id KAA11826; Mon, 25 Jul 2005 10:32:28 -0700 (PDT) In-Reply-To: <20050724212649.GA13210@nevyn.them.org> 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 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: gdb-patches@sources.redhat.com From: Marcel Moolenaar Subject: Re: [PATCH] New port: ia64-*-freebsd Date: Mon, 25 Jul 2005 17:32:00 -0000 To: Daniel Jacobowitz X-SW-Source: 2005-07/txt/msg00189.txt.bz2 On Jul 24, 2005, at 2:26 PM, Daniel Jacobowitz wrote: > 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? Exactly. It is possible and not just academic for multi-threaded applications to run out of backing store (e.g. by running into a guard page or something along those lines). There's no way for the processor to flush the dirty stacked registers if such is needed and it would not be possible for the kernel to write them out onto the backing store when creating a core dump. > 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. > >> 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. Agreed. >> 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. It's not just the core file operation that needs augmenting. In theory and practice all targets (ptrace, core, remote, etc) will need this. That's why I figured that a new target object would be acceptable. >> 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. Just FYI: I made a mistake. The number of dirty registers is not expressed in register count, but in the amount of bytes they occupy. This means that the amount of storage required to hold all possible dirty stacked registers is 16KB (or 2048 registers and NaT collections). This isn't nearly as bad a 128KB. Sorry for the confusion. >>>> 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. Correct. > 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. 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... :-) > Anyway, that's enough out of me. I'll leave the rest to Mark and the > ia64 maintainers. Thanks for comments. I appreciated it. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net