[RFA] [4/5] Use DWARF-2 DW_AT_artificial information

[Daniel Jacobowitz]

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