From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15213 invoked by alias); 26 Nov 2005 16:38:48 -0000 Received: (qmail 15205 invoked by uid 22791); 26 Nov 2005 16:38:47 -0000 X-Spam-Check-By: sourceware.org Received: from ip127.bb146.pacific.net.hk (HELO stl.com.hk) (202.64.146.127) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Nov 2005 16:38:46 +0000 Received: from 221.196.17.210.dyn.pacific.net.hk ([210.17.196.221] helo=[192.168.1.10]) by stl.com.hk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Eg2yt-0001mJ-On; Sun, 27 Nov 2005 00:32:55 +0800 Message-ID: <43888F83.7090603@tausq.org> Date: Sat, 26 Nov 2005 16:52:00 -0000 From: Randolph Chung User-Agent: Debian Thunderbird 1.0.2 (X11/20050331) MIME-Version: 1.0 To: Mark Kettenis CC: gdb@sources.redhat.com, dave@hiauly1.hia.nrc.ca, brobecker@adacore.com Subject: Re: Register numbers on hppa64 References: <200511260253.jAQ2rP7Z021130@hiauly1.hia.nrc.ca> <43880E6B.8060901@tausq.org> <200511261518.jAQFIN2K022588@elgar.sibelius.xs4all.nl> In-Reply-To: <200511261518.jAQFIN2K022588@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2005-11/txt/msg00578.txt.bz2 > Well, the ppc64 situation was a real mess, because the GCC people > screwed up, and used *their* internal mapping instead of the > officially documented numbers defined in the ELF ABI for DWARF2, and > this mapping was also used for GCC's exception handling info (which is > based on DWARF2). I'm not sure at all whether the issue has been > resolved. > > For hppa64 the situation is much better since... I thought one of the problems was that because the "dbx" and "dwarf" mappings in gcc are different, it would use the dbx mappings in debug info but the dwarf numbers elsewhere (e.g. for exception handling?). Is that an issue at all? >>Any comments or suggestions on how to sort this out? Should I just >>change gdb to match what gcc outputs? Should we change gcc to match what >>gdb expects? (safer?) > > ...we (GDB) are the ones that screwed up. Fortunately it's really > easy to fix things. We just need to provide the appropriate > xxx_reg_to_regnum functions in the acrhitecture vector. Right, this does work for gcc, but I wonder if I'm breaking HP compiler compatibility (which I cannot test...) > Actually the fix seems to be partly implemented already: there's a > #ifdeffed out hppa_dwarf_reg_to_regnum in hppa-linux-tdep.c. I think > it should be moved to hppa-tdep.c, and a 64-bit version should be > created. I wrote that code... :) but I think it's actually wrong; for 32-bit we have a 1:1 mapping between what gcc outputs for "dbx" register numbers in dwarf debug mode and the gdb internal register numbering, so we shouldn't need this mapping function for 32-bit. > Anyway, see i386-tdep.c for a complicated example of how > registers are mapped differently for several debugging formats and > executable formats. I believe HP compilers for hppa64-hpux also use dwarf; I don't see where the register numbering is documented in the ABI. I can easily implement a hppa64_dwarf_reg_to_regnum method, but I need to know if all hppa64 compilers have the same view of register numbers. randolph