From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21773 invoked by alias); 2 Aug 2006 02:55:39 -0000 Received: (qmail 21762 invoked by uid 22791); 2 Aug 2006 02:55:39 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Wed, 02 Aug 2006 02:55:36 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G86tO-0000EM-MC; Tue, 01 Aug 2006 22:55:30 -0400 Date: Wed, 02 Aug 2006 02:55:00 -0000 From: Daniel Jacobowitz To: Randolph Chung Cc: gdb@sources.redhat.com Subject: Is anyone using the HP compilers on PA-RISC with FSF GDB? Message-ID: <20060802025530.GA32090@nevyn.them.org> Mail-Followup-To: Randolph Chung , gdb@sources.redhat.com References: <4405B9C0.90505@tausq.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4405B9C0.90505@tausq.org> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00002.txt.bz2 On Wed, Mar 01, 2006 at 11:12:00PM +0800, Randolph Chung wrote: > Most of these have to do with how gdb handles c++ methods and member > variables, which makes me think that perhaps we should add some hooks to > the cp-abi layer to handle the type conversion logic. This takes care of > eval.c, valops.c, and maybe cp-valprint.c > I notice that HP's wdb has better support for some of these cases. If we > were to clean up the above it will be worthwhile to look through wdb and > try to merge in some of the logic there (mostly to deal with member > functions) > > Any thoughts? Is this even worth touching/fixing? Some of it certainly is worth fixing. I have a question, though, which I think I've asked before. GCC on HP/UX uses stabs, so only requires basic SOM support from GDB. That should be in decent shape still. But the stuff read by hpread.c is only generated by the HP compilers (cc and aCC). - Are these compilers still important for C? - Are these compilers still important for C++? I have not heard from any users of the FSF GDB with the HP compilers in a long time; for HP-specific features, I suspect more people use HP's WDB fork of GDB. If no one is using the HP support, I would like to remove it from the next release of GDB. The symbol reader (in hpread.c) is in dubious shape. It worked the last time Michael Chastain ran it through testing - but that was a few releases ago and I haven't heard of any substantial uses of it since. I've tried to make mechanical changes and interface cleanups to GDB's symbol readers in the past and gotten stuck up on this one, which is very hard for me to test. I could modernize it, but it would be a substantial (many weeks) time sink. I don't want to do that if no one is using it! There's also a lot of C++ hooks floating around in GDB for the aCC ABI, and I'm sure many of them don't do what was intended anymore. And the deprecated global variable Randolph was looking at is scattered around. Note, none of this applies to HP's compilers on IA64-HP/UX if that port is eventually supported in GDB. They use ELF and the Itanium C++ ABI, just like GCC. I believe they also use DWARF-2/DWARF-3. -- Daniel Jacobowitz CodeSourcery