From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23923 invoked by alias); 7 Mar 2007 00:23:59 -0000 Received: (qmail 23915 invoked by uid 22791); 7 Mar 2007 00:23:58 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 07 Mar 2007 00:23:52 +0000 Received: from dsl093-172-095.pit1.dsl.speakeasy.net ([66.93.172.95] helo=caradoc.them.org) by nevyn.them.org with esmtp (Exim 4.63) (envelope-from ) id 1HOjwc-0004vz-BT; Tue, 06 Mar 2007 19:23:50 -0500 Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HOjwb-0005L0-Pe; Tue, 06 Mar 2007 19:23:49 -0500 Date: Wed, 07 Mar 2007 00:23:00 -0000 From: Daniel Jacobowitz To: Gary Funck Cc: gdb@sourceware.org Subject: Re: DWARF3 DW_OP_push_object_address - requirement for deferred evaluation? Message-ID: <20070307002349.GA20195@caradoc.them.org> Mail-Followup-To: Gary Funck , gdb@sourceware.org References: <200703062353.l26Nr70j010496@intrepid.intrepid.com> <200703070013.l270DSJo010763@intrepid.intrepid.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200703070013.l270DSJo010763@intrepid.intrepid.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00109.txt.bz2 On Tue, Mar 06, 2007 at 04:11:29PM -0800, Gary Funck wrote: > Still, I was a bit confused by the code in add_partial_symbol(), which > checks to see if the symbol is external, and in that case seems to > assume that the location description is "simple" and can be computed > by decode_locdesc(), which evaluates to a fixed CORE_ADDR. If this > global variable in fact is allocated at runtime and its data and > size are described by a dope vector, then this assumption will not > hold? Is this one of those places that you were referring to > when you said that GDB sometimes pushes the object's address? No, it's an entirely different sort of problem. I think you'll be in some difficulty with globals with computed addresses, though I'm not sure how that would arise needing DW_OP_push_object_address. Normally, it only occurs today for local variables... I think there is some case where we evaluate simple location descriptions relative to the object address, but shouldn't. However, I do not remember the details. -- Daniel Jacobowitz CodeSourcery