This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] [4/5] Use DWARF-2 DW_AT_artificial information
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Elena Zannoni <ezannoni at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 15 May 2002 00:52:47 -0400
- Subject: Re: [RFA] [4/5] Use DWARF-2 DW_AT_artificial information
- References: <20020115153157.A28714@nevyn.them.org> <20020307154311.A19496@nevyn.them.org> <20020514211335.GA11766@nevyn.them.org> <15585.58783.368594.458392@localhost.redhat.com>
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