From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3311 invoked by alias); 19 Oct 2009 21:42:06 -0000 Received: (qmail 3302 invoked by uid 22791); 19 Oct 2009 21:42:06 -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 21:42:01 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id CFDFF130EC for ; Mon, 19 Oct 2009 14:41:59 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id C44AACDA3F; Mon, 19 Oct 2009 14:41:59 -0700 (PDT) Message-ID: <4ADCDBB7.2050500@vmware.com> Date: Mon, 19 Oct 2009 21:42: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> <4ADCA53C.2080703@vmware.com> <20091019183724.GA17923@caradoc.them.org> <4ADCBF6B.9050309@vmware.com> <20091019212817.GB3401@caradoc.them.org> In-Reply-To: <20091019212817.GB3401@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/msg00458.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Oct 19, 2009 at 12:35:07PM -0700, Michael Snyder wrote: >> * The requested location isn't cached, so we return zero. > > Simple: that isn't the interface of dcache_xfer_memory. It should > fill the cache. Trace it down to dcache_read_line. Well that's what it does. > >> The "until" command tries to read beyond the top of stack, >> which is fine for the running process and fine for the core >> file, but for some reason in this instance wants to go into >> dcache, where nothing currently should be cached. > > Beyond the *top*? And there's something mapped there? Arr, you know, "top" as in "TOS", as in the next location that would be used if you pushed something. Anyway, yes, that's what it does. dcache returns zero, and memory_xfer_partial bails out instead of trying the next target down the target stack.