From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19998 invoked by alias); 7 Mar 2007 00:13:38 -0000 Received: (qmail 19990 invoked by uid 22791); 7 Mar 2007 00:13:38 -0000 X-Spam-Check-By: sourceware.org Received: from intrepid.intrepid.com (HELO intrepid.intrepid.com) (192.195.190.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 Mar 2007 00:13:30 +0000 Received: from winnie ([192.195.190.51]) by intrepid.intrepid.com (8.13.8/8.13.8) with ESMTP id l270DSJo010763 for ; Tue, 6 Mar 2007 16:13:28 -0800 Message-Id: <200703070013.l270DSJo010763@intrepid.intrepid.com> From: "Gary Funck" To: Subject: RE: DWARF3 DW_OP_push_object_address - requirement for deferred evaluation? Date: Wed, 07 Mar 2007 00:13:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200703062353.l26Nr70j010496@intrepid.intrepid.com> 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/msg00108.txt.bz2 Gary Funck wrote: > Given that DW_OP_push_object_address was introduced in DWARF3 to > provide support for objects and data that are described by > "dope vectors", for which their address and other characteristics > such as array bounds are not known until runtime .... is the case > that the evaluation of a descriptor utilizing > DW_OP_push_object_address > must be deferred until either the referenced object is instantiated, > or the GDB user makes reference to the object? Scratch this question. I see where dwarf2_symbol_mark_computed(), var_decode_location() calls dwarf2_symbol_mark_computed() which copies the location description into the symbol table entry and marks the location as LOC_COMPUTED. 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?