From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28330 invoked by alias); 6 Nov 2002 21:52:55 -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 28321 invoked from network); 6 Nov 2002 21:52:53 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 6 Nov 2002 21:52:53 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D8EB63CC5; Wed, 6 Nov 2002 16:52:54 -0500 (EST) Message-ID: <3DC98F36.2030407@redhat.com> Date: Wed, 06 Nov 2002 13:52:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA/types: Clean up use of field bitsize References: <20020930010515.GA27762@nevyn.them.org> <20021030234148.GA22769@nevyn.them.org> <3DC97E66.70807@redhat.com> <20021106205431.GA5787@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-11/txt/msg00131.txt.bz2 > On Wed, Nov 06, 2002 at 03:41:10PM -0500, Andrew Cagney wrote: > >> >Does anyone have a comment on this patch? If not, I'll commit it in a >> >couple of days, after I'm added to the global write list. >> > >> >(The type code has no specific maintainer, the debug reader and >> >language parts I consider obvious, and the patch is over a month old >> >now.) > >> >> I'm mainly wondering if we're that desperate for memory space. >> >> I thought a data structure was added to GDB so that it could spot >> duplicate type info and, hence, keep its memory size down. > > > If so, I don't see it. The debug readers will create a new copy when > they hit a new definition. Sigh, looks depressingly like a proposal that fell flat :-( There are bcache's for macro and psymbol stuff but not types. > Besides, wasting memory is still bad. And that's not the reason I did > it, anyway: True, the real problem is (true?) the type duplication - gdb is wasting memory by duplicating type information - fixing that eliminates the problem removing the need for a micro optomization? Can't find the discussion :-( >> >>The goal is to allow more kinds of fields to be marked artificial - >> >>particularly data members. After this patch I'll submit the followup to >> >>mark DW_AT_artificial members as artificial types. > > > ... in other words, moving artificial out of loc without wasting an > additional 32 bits. I'm definitly not questioning this. Andrew