From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4090 invoked by alias); 8 Sep 2008 17:27:43 -0000 Received: (qmail 4081 invoked by uid 22791); 8 Sep 2008 17:27:42 -0000 X-Spam-Check-By: sourceware.org Received: from host0.dyn.jankratochvil.net (HELO host0.dyn.jankratochvil.net) (89.250.240.59) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 08 Sep 2008 17:27:07 +0000 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.2) with ESMTP id m88HR1Gj028465; Mon, 8 Sep 2008 19:27:01 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.2/Submit) id m88HR1s8028458; Mon, 8 Sep 2008 19:27:01 +0200 Date: Mon, 08 Sep 2008 17:27:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [patch] static_kind -> bit0, bit1 [Re: [gdb] Fortran dynamic arrays] Message-ID: <20080908172701.GA18549@host0.dyn.jankratochvil.net> References: <20080818111120.GE16894@adacore.com> <200808181553.m7IFrG3w005270@d12av02.megacenter.de.ibm.com> <48A59B3C.9050801@net-b.de> <20080818111120.GE16894@adacore.com> <20080907115637.GA12939@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2008-09/txt/msg00171.txt.bz2 On Mon, 08 Sep 2008 17:30:47 +0200, Tom Tromey wrote: > >>>>> "Jan" == Jan Kratochvil writes: > > Jan> The patch modifies a lot of sources trying to follow the new > Jan> style of main_type bitfields instead of the former FLAGS > Jan> variable. I do not think current main_type layout is right but > Jan> the patch tries to follow the current main_type style. > > Do you mean the main_type layout after this patch, or before this patch? > If before -- could you be more specific? Both before and it gets a bit worse after. There should be a union with fields for each very specific TYPE_CODE_*. TYPE_CODE_ARRAY is terrible - it has always exactly NFIELDS==1 with fields[0].type->main_type pointing to TYPE_CODE_RANGE having exactly NFIELDS==2 (for the lower and upper bound). If we try so much to save some main_type memory: * fields[0].loc is not used. * nfields everywhere is not used. * main_type for TYPE_CODE_RANGE is not used as DW_TAG_subrange_type's DW_AT_type is stored into TYPE_CODE_RANGE's TYPE_TARGET_TYPE. We should have just one TYPE_CODE_ARRAY main_type pointing to the element-type (DW_TAG_array_type's DW_AT_type - which is right as its target_type) also also one simple pointer to the index type (DW_TAG_subrange_type's DW_AT_type - currently stored in TYPE_CODE_RANGE's target_type). target_type, vptr_fieldno, vptr_basetype and some cases of fields[] is used only for some types and for other types they are left unused. These fields should be moved to the type_specific union. fields[] with nfields should be moved into the type_specific union for specific types TYPE_CODE_FUNC, TYPE_CODE_STRUCT and some others. Simple union would make it all more clear, optimal for the memory size and even allocatable with variable length. Some better encapsulation would benefit the dynamic bounds I hacked into the current code. There should be a virtual method with MAIN_TYPE containing generic abstract class type. class debuginfo_value { virtual LONGEST get() = 0; }; class dwarf2_integer : debuginfo_value { virtual LONGEST get() { ... }; }; class dwarf2_block : debuginfo_value { virtual LONGEST get() { ... }; }; class main_type { ...; debuginfo_value upper_bound_value; ... }; LONGEST is not right as we need to return also unbound/undefined results. Just C++ requires pointer (or reference) as upper_bound_value which is inefficient so a C implementation (knowing the maximum size of all the inherited classes) should be better here, right? If the memory of main_type is so critical (I doubt so but i did not measure it) in my Fortran/dynamic-bounds patch main_type had to get three new pointers almost always being NULL. These three pointers may need to be set for any type so the base struct main_type has to be extended for them. We could instead use the Amiga "tags" data format with variable block size allocation (but sure slow access time which should not matter here): struct main_type { ...; void *tags[1]; }; memcpy (main_type->tags, { DW_AT_allocated, 0x601010, DW_AT_associated, 0x610348, NULL /* terminator */ }); Regards, Jan