From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20062 invoked by alias); 15 Jul 2005 02:16:41 -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 20054 invoked by uid 22791); 15 Jul 2005 02:16:36 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 15 Jul 2005 02:16:36 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1DtFkg-0007E2-Az; Thu, 14 Jul 2005 22:16:34 -0400 Date: Fri, 15 Jul 2005 02:16:00 -0000 From: Daniel Jacobowitz To: Marcel Moolenaar Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] New port: ia64-*-freebsd Message-ID: <20050715021634.GA27723@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2845064d598c2c3d2433909ea136f830@cup.hp.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg00126.txt.bz2 On Thu, Jul 14, 2005 at 07:08:09PM -0700, Marcel Moolenaar wrote: > >The comment on TARGET_OBJECT_DIRTY says "see ia64-tdep.c", which has > >basically no comments explaining what it does, or why it is necessary > >for FreeBSD when it isn't for GNU/Linux. > > A quick explanation then: > Stacked registers are either dirty or flushed when it comes to > accessing them. Stacked registers that are flushed have been > written to the backing store by the processor -- they are in > the target's memory. Stacked registers that are dirty are still > in the processor. They end up on the kernel's stack of the > corresponding process whenever there's a kernel context switch. > Linux abstracts this and allows them both to be read and written > the same way. FreeBSD doesn't abstract this. The reason > FreeBSD doesn't abstract it is because it is not always possible > to do so, nor is it always beneficial to do so. > So, in order for gdb to handle all possible failure modes, it > needs to be aware of the difference so that it can access the > registers accordingly. > > A typical example of a failure mode that cannot be debugged with > abstraction, is a core file created when the backing store overflows. > The kernel will not be able to move the dirty stacked registers > in the core file, because there's no room for it (there's no space > on the backing store where they would normally go). They need to > be written into the core file as a note (like the general registers) > and fetched seperately. Thank you! This needs to be described in the source somewhere. I'd like to see a more descriptive name for TARGET_OBJECT_DIRTY, also, though I don't have any advice - right now it would be a good place to stick a dirty hack. Or dirty laundry. > >The corelow.c implementation of TARGET_OBJECT_DIRTY looks pretty > >sketchy for target-independent code. > > What exactly do you mean? + case TARGET_OBJECT_DIRTY: + { + ULONGEST addr; + addr = *(ULONGEST*)annex + offset; + if (readbuf) + return (*ops->deprecated_xfer_memory) (addr, readbuf, len, + 0/*read*/, NULL, ops); + if (writebuf) + return (*ops->deprecated_xfer_memory) (addr, writebuf, len, + 1/*write*/, NULL, ops); + return -1; + } + 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? >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"? > > >You have a lot of non-GNUish formatting issues - mostly the pesky > >spacing rules. > > No doubt. I'm not used to the GNU formatting :-) You did better than most people not used to it can manage :-) -- Daniel Jacobowitz CodeSourcery, LLC