From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12131 invoked by alias); 19 Oct 2009 17:49:37 -0000 Received: (qmail 12123 invoked by uid 22791); 19 Oct 2009 17:49:37 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 19 Oct 2009 17:49:33 +0000 Received: from mailhost4.vmware.com (mailhost4.vmware.com [10.16.67.124]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 42688130E6 for ; Mon, 19 Oct 2009 10:49:31 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost4.vmware.com (Postfix) with ESMTP id 37253C9C1C; Mon, 19 Oct 2009 10:49:31 -0700 (PDT) Message-ID: <4ADCA53C.2080703@vmware.com> Date: Mon, 19 Oct 2009 17:49:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Michael Snyder , "gdb-patches@sourceware.org" Subject: Re: Seems like a bug in target_read_stack / dcache_xfer_memory? References: <4ADB9759.7060305@vmware.com> <20091018225134.GA30546@caradoc.them.org> In-Reply-To: <20091018225134.GA30546@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00432.txt.bz2 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. ;-( >> Anyway, I don't even remember now how I figured this out, but >> I *THINK* what all these guys return is either 0 for success, >> or an errno value less than zoro. > > No, they return: > > the number of bytes actually transfered, zero when no > further transfer is possible, and -1 when the transfer is not > supported. 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.