From: Daniel Jacobowitz <drow@mvista.com>
To: Elena Zannoni <ezannoni@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] [1/5] Use DWARF-2 DW_AT_artificial information
Date: Wed, 16 Jan 2002 16:42:00 -0000 [thread overview]
Message-ID: <20020116194205.A29972@nevyn.them.org> (raw)
In-Reply-To: <15430.715.800287.164802@localhost.cygnus.com>
On Wed, Jan 16, 2002 at 05:46:35PM -0500, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
> > There are two things which gcc 3.x's DWARF-2 support marks as artificial:
> > - arguments (to constructors only?)
> > - methods provided by the compiler (any of operator=, copy constructor,
> > default constructor, virtual thunks).
> >
> > In particular we do not want to print virtual thunks, and I don't see any
> > reason to preserve printing operator= et al. if we don't have to (and if the
> > user didn't provide them himself).
> >
> > This patch is the first in a series of five to add support for both of these
> > things. It lays the groundwork for identifying artificial method arguments.
> > The only interesting bit is removing an obsolete use of TYPE_FIELD_BITPOS -
> > at one point, TYPE_FIELD_BITPOS on a function's argument was an index into
> > the list of arguments. We never used this anywhere and only the HP readers
> > set it. I delete it so that I can re-use that space.
> >
>
> Have you tested on hpux? It doesn't seem like it should have an effect,
> but....
No. I would love to if someone on this list could get me an HP/UX
account - especially one with the HP C++ compiler installed!
> > I have tested the patches all together, but not individually; I'll commit
> > them separately when approved, but I'm going to wait until they've all been
> > approved. They should work on their own, though.
> >
>
> I think this is a bit dangerous assumption, do they compile on their own?
>
> > OK to commit this one?
>
> Looks ok to me. This is a fairly self-contained patch. I would think
> you can check this in, for start, while I look at the rest of the
> series. It should have no visible effect on GDB's behavior, right?
It certainly should have no effect. I haven't compiled them on their
own - I would before committing certainly - just eyeballed them.
I'll test and commit this along with any others approved by the time I
get a chance to test - tomorrow, probably. The type system doesn't
have an explicit maintainer, so I assume that you can approve it.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2002-01-17 0:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-15 12:27 Daniel Jacobowitz
2002-01-16 15:33 ` Elena Zannoni
2002-01-16 15:41 ` Elena Zannoni
2002-01-16 16:42 ` Daniel Jacobowitz [this message]
2002-01-20 11:12 ` Daniel Jacobowitz
2002-01-20 11:38 ` Elena Zannoni
2002-01-20 11:41 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020116194205.A29972@nevyn.them.org \
--to=drow@mvista.com \
--cc=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox