From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25921 invoked by alias); 3 Feb 2013 09:20:50 -0000 Received: (qmail 25912 invoked by uid 22791); 3 Feb 2013 09:20:49 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_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; Sun, 03 Feb 2013 09:20:40 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r139KPiD027902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 3 Feb 2013 04:20:33 -0500 Received: from host2.jankratochvil.net ([10.3.113.16]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r139K1wS001415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 3 Feb 2013 04:20:12 -0500 Date: Sun, 03 Feb 2013 09:20:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [2/3] RFC: merge symbol "ops" and "aclass" fields Message-ID: <20130203092001.GD16948@host2.jankratochvil.net> References: <8738y1hzzz.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8738y1hzzz.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2013-02/txt/msg00053.txt.bz2 Hi Tom, such a minor sanity check, not sure if worth it: On Wed, 16 Jan 2013 17:08:32 +0100, Tom Tromey wrote: > --- a/gdb/symtab.h > +++ b/gdb/symtab.h > @@ -584,6 +587,30 @@ struct symbol_register_ops > int (*register_number) (struct symbol *symbol, struct gdbarch *gdbarch); > }; > > +/* Objects of this type are used to find the address class and the > + various computed ops vectors of a symbol. */ > + > +struct symbol_impl > +{ > + enum address_class aclass; > + > + /* Used with LOC_COMPUTED. */ > + const struct symbol_computed_ops *ops_computed; > + > + /* Used with LOC_REGISTER and LOC_REGPARM_ADDR. */ > + const struct symbol_register_ops *ops_register; > + > + /* Used to store a per-symbol-reader datum. */ > + const void *reader_datum; These three fields could be union. > +}; [...] > @@ -679,10 +692,22 @@ struct symbol > #define SYMBOL_TYPE(symbol) (symbol)->type > #define SYMBOL_LINE(symbol) (symbol)->line > #define SYMBOL_SYMTAB(symbol) (symbol)->symtab > -#define SYMBOL_COMPUTED_OPS(symbol) (symbol)->ops.ops_computed > -#define SYMBOL_REGISTER_OPS(symbol) (symbol)->ops.ops_register > +#define SYMBOL_COMPUTED_OPS(symbol) \ > + ((symbol_impls[(symbol)->aclass_index]).ops_computed) > +#define SYMBOL_REGISTER_OPS(symbol) \ > + ((symbol_impls[(symbol)->aclass_index]).ops_register) > +#define SYMBOL_READER_DATUM(symbol) \ > + ((symbol_impls[(symbol)->aclass_index]).reader_datum) > #define SYMBOL_LOCATION_BATON(symbol) (symbol)->aux_value And these accessors could gdb_assert impl->ACLASS. Currently if ACLASS does not match it returns NULL, which would (correctly) crash on dereferencing a method but such coding bug would not be noticed during accesses like: if (SYMBOL_COMPUTED_OPS (sym) == &dwarf2_loclist_funcs) Thanks, Jan