From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4315 invoked by alias); 9 Apr 2003 05:05:52 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 4308 invoked from network); 9 Apr 2003 05:05:51 -0000 Received: from unknown (HELO zenia.red-bean.com) (12.222.151.100) by sources.redhat.com with SMTP; 9 Apr 2003 05:05:51 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h3956gFq020448; Wed, 9 Apr 2003 00:06:43 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h3956bIl020444; Wed, 9 Apr 2003 00:06:37 -0500 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Location list support for DWARF-2 References: <20030310160628.GA1988@nevyn.them.org> <20030312224043.GA8247@nevyn.them.org> From: Jim Blandy Date: Wed, 09 Apr 2003 05:05:00 -0000 In-Reply-To: <20030312224043.GA8247@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-04/txt/msg00152.txt.bz2 This looks good to me --- please commit it, once you've addressed the minor things I mention here. (Yay!) Daniel Jacobowitz writes: > > Rather than putting 'if (foo->is_list)' everywhere, why not just > > introduce a separate 'struct location_funcs' for location lists? > > Aside from just being cleaner, you'll save a word in each baton. > > Actually, it won't save any space to remove is_list: it goes into the > padding between size and the following CORE_ADDR/pointer. It does save > space for non-location-list variables though, because of the base > address, so I think it's a good idea. Okay, I think that's a big improvement. > It requires introducing one annoying hack in dwarf_expr_frame_base > but I'm not terribly upset by it. I can think of a nice solution in C++, but it would lose so much in the translation to C that it's not worth it. > +struct dwarf2_loclist_baton > +{ > + CORE_ADDR base_address; > + unsigned char *data; > + unsigned short size; > + struct objfile *objfile; > +}; The fields of this structure need to be documented, as do those of dwarf2_locexpr_baton. > + { > + dwarf2_invalid_attrib_class_complaint ("location description", > + SYMBOL_NATURAL_NAME (sym)); > + baton->size = 0; > + baton->data = NULL; > + } dwarf2_evaluate_loc_desc isn't prepared to handle this; it'll get an error when it tries to fetch the top value off the stack after evaluating no location instructions, won't it? It should probably return a value with its "optimized_out" flag set.