From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26976 invoked by alias); 19 Oct 2009 18:37:32 -0000 Received: (qmail 26962 invoked by uid 22791); 19 Oct 2009 18:37:32 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Oct 2009 18:37:27 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 06796105BB; Mon, 19 Oct 2009 18:37:26 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id D509E10576; Mon, 19 Oct 2009 18:37:25 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1Mzx6i-0004pN-PV; Mon, 19 Oct 2009 14:37:24 -0400 Date: Mon, 19 Oct 2009 18:37:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: "gdb-patches@sourceware.org" Subject: Re: Seems like a bug in target_read_stack / dcache_xfer_memory? Message-ID: <20091019183724.GA17923@caradoc.them.org> Mail-Followup-To: Michael Snyder , "gdb-patches@sourceware.org" References: <4ADB9759.7060305@vmware.com> <20091018225134.GA30546@caradoc.them.org> <4ADCA53C.2080703@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ADCA53C.2080703@vmware.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00439.txt.bz2 On Mon, Oct 19, 2009 at 10:43:24AM -0700, Michael Snyder wrote: > drow@false.org wrote: > >On Sun, Oct 18, 2009 at 03:31:53PM -0700, Michael Snyder wrote: > >> The arguments and return > >> value are just as for target_xfer_partial > > > >The comment is on the logical home of this method, other places should > >refer to the header: the definition of to_xfer_partial in struct > >target_ops in target.h. > > OK, shouldn't we say so? I want to drop this conversation, > though, and focus on the code problem. Sorry again for my > aggrieved tone yesterday -- I was tired. ;-( Sure - I'm just as annoyed by the tangle as you are - I just remember hunting for this comment myself :-) > OK, so suppose dcache_xfer_memory returns zero in this context. > That means no transfer is possible. Shouldn't we give the other > targets on the stack a shot? > > In the case I'm looking at, the next target down is a core file, > and I know it has the memory location available. If I force gdb > out of this error return, core_xfer_partial will succeed. You haven't really described the situation, so I'm guessing. But the problem can't be in the code you cited. It's got to be further down the call stack. -- Daniel Jacobowitz CodeSourcery