Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: randolph@tausq.org
Cc: gdb@sources.redhat.com, dave@hiauly1.hia.nrc.ca, brobecker@adacore.com
Subject: Re: Register numbers on hppa64
Date: Sat, 26 Nov 2005 17:32:00 -0000	[thread overview]
Message-ID: <200511261719.jAQHJnTd015739@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <43888F83.7090603@tausq.org> (message from Randolph Chung on Sun, 	27 Nov 2005 00:38:27 +0800)

> Date: Sun, 27 Nov 2005 00:38:27 +0800
> From: Randolph Chung <randolph@tausq.org>
> 
> > 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


  reply	other threads:[~2005-11-26 17:20 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200511260253.jAQ2rP7Z021130@hiauly1.hia.nrc.ca>
2005-11-26  9:23 ` Randolph Chung
2005-11-26 15:54   ` Mark Kettenis
2005-11-26 16:52     ` Randolph Chung
2005-11-26 17:32       ` Mark Kettenis [this message]
2005-11-26 18:50         ` John David Anglin
2005-11-27 16:30         ` Randolph Chung
2005-11-26 17:34       ` John David Anglin
2005-11-26 17:20     ` John David Anglin
2005-11-26 17:13   ` John David Anglin
2005-11-26 17:52     ` Mark Kettenis
2005-11-26 18:00       ` John David Anglin
2005-11-26 18:31         ` Mark Kettenis
2005-11-27  4:30           ` John David Anglin
2005-11-27 15:10             ` Randolph Chung
2005-11-27 16:52               ` John David Anglin
2005-11-27 17:42               ` Mark Kettenis

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=200511261719.jAQHJnTd015739@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=brobecker@adacore.com \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=gdb@sources.redhat.com \
    --cc=randolph@tausq.org \
    /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