This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Register numbers on hppa64


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]