From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6638 invoked by alias); 2 Sep 2009 20:43:13 -0000 Received: (qmail 6622 invoked by uid 22791); 2 Sep 2009 20:43:12 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 02 Sep 2009 20:43:04 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n82KgjW9002561; Wed, 2 Sep 2009 16:42:45 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n82Kgicx030845; Wed, 2 Sep 2009 16:42:44 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n82KghoM022480; Wed, 2 Sep 2009 16:42:43 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 1480B378242; Wed, 2 Sep 2009 14:42:43 -0600 (MDT) From: Tom Tromey To: Doug Evans Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [RFA] Use data cache for stack accesses References: <7e6c8d660907081308r13bff580rdcf4822c77df8403@mail.gmail.com> <200907082146.40513.pedro@codesourcery.com> Reply-To: tromey@redhat.com Date: Wed, 02 Sep 2009 20:43:00 -0000 In-Reply-To: (Doug Evans's message of "Mon, 24 Aug 2009 17:48:30 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-09/txt/msg00069.txt.bz2 >>>>> "Doug" == Doug Evans writes: Doug> * dwarf2loc.c (dwarf2_evaluate_loc_desc): Mark values on stack with Doug> set_value_stack. I ran across this while merging the DW_OP_*_value patch. Do we really know that such values always come from the stack? It seems plausible to me that this is the case in practice, but aren't compilers free to refer to any memory at all from a DWARF expression? Tom