From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30992 invoked by alias); 17 Jan 2002 00:42:00 -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 30953 invoked from network); 17 Jan 2002 00:41:59 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 17 Jan 2002 00:41:59 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16R0d4-0007qf-00; Wed, 16 Jan 2002 19:42:06 -0500 Date: Wed, 16 Jan 2002 16:42:00 -0000 From: Daniel Jacobowitz To: Elena Zannoni Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] [1/5] Use DWARF-2 DW_AT_artificial information Message-ID: <20020116194205.A29972@nevyn.them.org> Mail-Followup-To: Elena Zannoni , gdb-patches@sources.redhat.com References: <20020115152720.A28147@nevyn.them.org> <15430.715.800287.164802@localhost.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15430.715.800287.164802@localhost.cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-01/txt/msg00467.txt.bz2 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