From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 423 invoked by alias); 26 Nov 2005 17:20:05 -0000 Received: (qmail 411 invoked by uid 22791); 26 Nov 2005 17:20:04 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 26 Nov 2005 17:20:01 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id jAQHJn50004967; Sat, 26 Nov 2005 18:19:49 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id jAQHJn0p005271; Sat, 26 Nov 2005 18:19:49 +0100 (CET) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id jAQHJnTd015739; Sat, 26 Nov 2005 18:19:49 +0100 (CET) Date: Sat, 26 Nov 2005 17:32:00 -0000 Message-Id: <200511261719.jAQHJnTd015739@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: randolph@tausq.org CC: gdb@sources.redhat.com, dave@hiauly1.hia.nrc.ca, brobecker@adacore.com In-reply-to: <43888F83.7090603@tausq.org> (message from Randolph Chung on Sun, 27 Nov 2005 00:38:27 +0800) Subject: Re: Register numbers on hppa64 References: <200511260253.jAQ2rP7Z021130@hiauly1.hia.nrc.ca> <43880E6B.8060901@tausq.org> <200511261518.jAQFIN2K022588@elgar.sibelius.xs4all.nl> <43888F83.7090603@tausq.org> 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/msg00581.txt.bz2 > Date: Sun, 27 Nov 2005 00:38:27 +0800 > From: Randolph Chung > > > 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? Oh wait, now I see. I was a bit confused. Yes, the GCC people did screw up. It's silly to use to use a different encoding for DWARF2 CFI than for other DWARF2 sections. > > >>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...) If fixing things for GCC means that we break the HP compilers, we should do so: GDB is part of the GNU project so its primary job should be supporting the GNU compiler, not some proprietary compiler. Unfortunately the encoding used for .debug_frame (proper DWARF CFI) and .eh_frame (GCC's bastardized DWARF CFI used for exception handling) is presumed to be the same in GCC, and changing the .eh_frame encoding in't an option, since that would break binary compatibility for code that uses C++ exception handling. It looks like we need some GCC_DEVELOPERS_DONT_THINK_BEFORE_THEY_CODE_MAP_REG_TO_REGNUM mapping. (sorry Dave) Sigh.... Well, let's call it dwarf2_frame_reg_to_regnum(). > > 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. No, even for 32-bit stuff there is a mapping: /* How to renumber registers for dbx and gdb. Registers 0 - 31 remain unchanged. Registers 32 - 87 are mapped to 72 - 127 Register 88 is mapped to 32. */ But you're right, it's not right to use this encoding for decoding DWARF CFI since that uses the a different mapping (but that mapping isn't 1:1). Mark