From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14924 invoked by alias); 15 May 2002 04:52:48 -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 14869 invoked from network); 15 May 2002 04:52:44 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 15 May 2002 04:52:44 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 177qmN-0003pP-00; Wed, 15 May 2002 00:52:47 -0400 Date: Tue, 14 May 2002 21:52:00 -0000 From: Daniel Jacobowitz To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] [4/5] Use DWARF-2 DW_AT_artificial information Message-ID: <20020515045247.GA14330@nevyn.them.org> Mail-Followup-To: Elena Zannoni , gdb-patches@sources.redhat.com References: <20020115153157.A28714@nevyn.them.org> <20020307154311.A19496@nevyn.them.org> <20020514211335.GA11766@nevyn.them.org> <15585.58783.368594.458392@localhost.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15585.58783.368594.458392@localhost.redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-05/txt/msg00581.txt.bz2 On Wed, May 15, 2002 at 12:35:43AM -0400, Elena Zannoni wrote: > Daniel Jacobowitz writes: > > I hate to be a nag, but this patch would be useful for some of my > > current work. Do you have a chance to look at it? > > > > You are completely right, sorry. I wonder if MichaelC could kindly > run it through his test harness. That was a big help with yesterday's > patch. And if you can run the tests with the maintainers file script. (Don't bother, Michael, it doesn't apply any more.) I looked at this in passing and noticed it touched some of the same files I was working on. I completely forgot that my previous patches completely invalidated it :) Sorry for wasting your time. > How much does the size increase by adding this new struct? I don't have any numbers, unfortunately. I'll try to get some, unless I think of a better way to do it... > I have looked at it when you first posted it, and I had some > questions, I have to go fish for them again. But basically, the > motivation for this change is what? You need to handle the dwarf2 > information for artificial arguments, right? So that needs a change in > dwarf2read.c. How does that bring about the change in the type > structure? Can you explain a bit? (my brain gets lazy at this time). OK, let me explain this a bit. Right now the only information we save for a method type are some flags, the return type, and a list of argument types - just as an array of struct type *. I needed another bit per argument, and I couldn't find anywhere to put it. Maintaining a separate bitmap is even uglier. > In the meantime, I noticed that the hp-symtab-read.c changes are not > mentioned in the ChangeLog (well, now it is hpread.c). Also now you > have a bunch of type->code instead of TYPE_CODE(). I tried to apply > the patch to the current sources, but it failed in several files. I > tried to resolve the conflicts by hand but the compilation died in > valops.c, gdbypes.c and c-typeprint.c. I think the rename of type to > main_type needs to be taken into account as well. > I get these 2 kinds of errors: > /home/ezannoni/sources/src/gdb/c-typeprint.c:171: structure has no member named `code' > /home/ezannoni/sources/src/gdb/gdbtypes.c:2750: structure has no member named `type_specific' Yep, those are symptomatic of missing accessor macros. Those used to be members of struct type. > I noticed this quite ugly syntax. I know you didn't introduce it, but, > I wonder why it's needed: > 't1[!staticp].type' and 'for (i = !staticp;....)' Basically, it is just shorthand for "the first non-THIS argument". I don't know who introduced it; one of the past C++ maintainers, possibly Tiemann, seems to have been very fond of that syntax. I'm killing it where I run into it. > I think you also need to update a few comments in gdbtypes.h when > introducing the new method_args field. > > Is there any better naming scheme for TYPE_FN_FIELD_ARGS and > TYPE_FN_FIELD_ARG? I am always a bit worried when identifiers differ > by just one char. Before I clean this up, do you have any better ideas on where to record the new flag? Maybe a separate bitmap would be better after all. Less intrusive, certainly. By the way, I intend to use this flag from stabs also; the C++ ABI can tell us when the int used to control constructors/destructors is artificial with acceptably high accuracy, I think. That'll improve our display of them somewhat. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer