Register numbers on hppa64

Register numbers on hppa64

[Randolph Chung]

OK, this is a mess....:)

Apparently we now have at least three different register numbering 
schemes for hppa64:

1) gcc "dbx":
0-31: r0-r31
72-135: fr0-fr31 (odd numbers are not used)
60: sar

2) gcc dwarf frame:
unity mapping, so:
0-31: r0-r31
32-59: fr4-fr31
60: sar

3) gdb
0-31: r0-r31
32-63: sar, pcoqh, pcsqh, other "special" registers
64-95: fr0-fr31

4) HP compilers
???

Joel, does your GNAT C compiler output something different from the 
above? :-)

Obviously this will not work....

The gdb numbering scheme seems to be there for a long time. I don't know 
if this is the way HP numbers registers in their debug format. Does 
anybody have a pointer to this information?

I see that in late 2003/early 2004 there was a discussion about archs 
with mismatched "dbx register numbers" vs "dwarf CFI register numbers" 
on gcc@gcc.gnu.org and gdb-patches@gcc.gnu.org. Back then the discussion 
was about ppc64, although i was not quite sure what was the conclusion 
of those discussions. hppa64 is in a similar situation.

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?)

randolph

Re: Register numbers on hppa64

[Mark Kettenis]

> Date: Sat, 26 Nov 2005 15:27:39 +0800
> From: Randolph Chung <randolph@tausq.org>
> 
> OK, this is a mess....:)

It's not too bad ;-).

> Apparently we now have at least three different register numbering 
> schemes for hppa64:
> 
> 1) gcc "dbx":
> 0-31: r0-r31
> 72-135: fr0-fr31 (odd numbers are not used)
> 60: sar

gcc/config/pa/pa64-regs.h says:

/* How to renumber registers for dbx and gdb.

   Registers 0  - 31 remain unchanged.

   Registers 32 - 59 are mapped to 72, 74, 76 ...

   Register 60 is mapped to 32.  */

So it seems that the last line of your list should be:

32: sar

> 2) gcc dwarf frame:
> unity mapping, so:
> 0-31: r0-r31
> 32-59: fr4-fr31
> 60: sar
> 
> 3) gdb
> 0-31: r0-r31
> 32-63: sar, pcoqh, pcsqh, other "special" registers
> 64-95: fr0-fr31

This is GDB's *internal* register mapping.  On some targets we've been
careful and made that internal register mapping match the one used by
the "standard" compiler/debugger on that target, for most targets this
is not the case.

> 4) HP compilers
> ???

I'm not even sure what debug format HP's 64-bit compilers use.  The
fact that the dbx mapping is a bit weird, suggests that there has been
a system that used stabs with that register mapping once.  Not sure if
that was HP-UX or the old BSD variant that ran on PA-RISC systems.

> Joel, does your GNAT C compiler output something different from the 
> above? :-)
> 
> Obviously this will not work....
> 
> The gdb numbering scheme seems to be there for a long time. I don't know 
> if this is the way HP numbers registers in their debug format. Does 
> anybody have a pointer to this information?

Since it's GDB's internal numbering it's perfectly well possible that
the numbering scheme isn't used by any debug format at all.  I think
it's mostly dictated by the layout of "struct save_state" from HP-UX.
Could be that this is the numbering scheme used by HP though.

> I see that in late 2003/early 2004 there was a discussion about archs 
> with mismatched "dbx register numbers" vs "dwarf CFI register numbers" 
> on gcc@gcc.gnu.org and gdb-patches@gcc.gnu.org. Back then the discussion 
> was about ppc64, although i was not quite sure what was the conclusion 
> of those discussions. hppa64 is in a similar situation.

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...

> 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.

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.  Anyway, see i386-tdep.c for a complicated example of how
registers are mapped differently for several debugging formats and
executable formats.

Mark

Re: Register numbers on hppa64

[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?

>>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

Re: Register numbers on hppa64

[Mark Kettenis]

> 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

Re: Register numbers on hppa64

[John David Anglin]

> It looks like we need some
> GCC_DEVELOPERS_DONT_THINK_BEFORE_THEY_CODE_MAP_REG_TO_REGNUM mapping.
> (sorry Dave) Sigh....
~

> > 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).

I believe that we have a 1:1 mapping between gcc's frame and dbx
numbers at the moment.  I haven't fully thought this through but
the save state contains information that we don't currently
copy to the frame state.  We could record this frame state data
if there was a way to restore it.  Thus, I don't believe that
gcc's sets of frame and dbx registers have to be the same.  For
example, there is no direct way in gcc to set the floating point
status registers.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Register numbers on hppa64

[Randolph Chung]

> 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.

While I do not disagree either from a pragmatic (ability to test) and a 
philosophical point of view, if somebody who cares speaks up with the 
required info I think we should try to continue to support the HP 
compilers. Of course if we cannot get to the required information we 
shouldn't hold up progress in supporting gcc.

> 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().

I'll submit a patch to gdb-patches to implement this for hppa64 shortly.

randolph

Re: Register numbers on hppa64

[John David Anglin]

> 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.

I can't provide a definitive answer but I don't think so.  We see
debug information in sections like the following:

  [34] .debug_header     PROGBITS         0000000000000000  00004800
	 0000000000000030  0000000000000000           0     0     4
  [35] .debug_gntt       PROGBITS         0000000000000028  00004830
	 00000000000001a0  0000000000000000           0     0     4
  [36] .debug_lntt       PROGBITS         0000000000001398  000049d0
	 00000000000018f0  0000000000000000           0     0     4

I think this is a modification of the debug format documented in the
32-bit runtime.  At one time, I think there was support for this format
in gdb (wdb?).  However, the practical use is limited as HP libraries
don't contain debug information.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Register numbers on hppa64

[John David Anglin]

> It's not too bad ;-).
> 
> > Apparently we now have at least three different register numbering 
> > schemes for hppa64:
> > 
> > 1) gcc "dbx":
> > 0-31: r0-r31
> > 72-135: fr0-fr31 (odd numbers are not used)
> > 60: sar
> 
> gcc/config/pa/pa64-regs.h says:
> 
> /* How to renumber registers for dbx and gdb.
> 
>    Registers 0  - 31 remain unchanged.
> 
>    Registers 32 - 59 are mapped to 72, 74, 76 ...
> 
>    Register 60 is mapped to 32.  */
> 
> So it seems that the last line of your list should be:
> 
> 32: sar

Also, gcc register 32 is fr4, so the floating-point registers match
the gdb numbers.  Odd "floating-point" numbers aren't used.

> > 3) gdb
> > 0-31: r0-r31
> > 32-63: sar, pcoqh, pcsqh, other "special" registers
> > 64-95: fr0-fr31
> 
> This is GDB's *internal* register mapping.  On some targets we've been
> careful and made that internal register mapping match the one used by
> the "standard" compiler/debugger on that target, for most targets this
> is not the case.
> 
> > 4) HP compilers
> > ???
> 
> I'm not even sure what debug format HP's 64-bit compilers use.  The
> fact that the dbx mapping is a bit weird, suggests that there has been
> a system that used stabs with that register mapping once.  Not sure if
> that was HP-UX or the old BSD variant that ran on PA-RISC systems.

I don't think stabs has been used with GCC on hppa64.

> Since it's GDB's internal numbering it's perfectly well possible that
> the numbering scheme isn't used by any debug format at all.  I think
> it's mostly dictated by the layout of "struct save_state" from HP-UX.
> Could be that this is the numbering scheme used by HP though.

That's also my impression.  However, since PA 2.0, the layout of
"struct save_state" is more complicated.  In the 32-bit case,
access depends on whether or not UseWideRegs (ssp) is true or not.
It's not entirely clear how one would derive an unique numbering.

Really, the issue seems to be converting the dbx and frame numbers
to gdb's internal numbering.  This is a nop for the dbx numbers but
not for the frame numbers.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Register numbers on hppa64

[John David Anglin]

> OK, this is a mess....:)
> 
> Apparently we now have at least three different register numbering 
> schemes for hppa64:
> 
> 1) gcc "dbx":
> 0-31: r0-r31
> 72-135: fr0-fr31 (odd numbers are not used)

GCC regno 32 is fr4.  fr0 through fr3 aren't known to GCC.  So, we
actually have:

72, 74, ...: fr4, fr5, ...

This appears compatible with the gdb mapping.

> 60: sar

I believe that sar is 32 in the gcc dbx mapping.

> 2) gcc dwarf frame:
> unity mapping, so:
> 0-31: r0-r31
> 32-59: fr4-fr31
> 60: sar

This can't change (at least not easily).  This is tied to the
allocation of the dwarf_reg_size_table.s

The only way this can change is by adding the control and space
registers that GCC doesn't currently know about to GCC's register
tables.  This will impact performance to some extent.  There's
also no easy way to use these registers as they are mostly priviledged
or require special access techniques.

> 3) gdb
> 0-31: r0-r31
> 32-63: sar, pcoqh, pcsqh, other "special" registers
> 64-95: fr0-fr31
> 
> 4) HP compilers
> ???

This doesn't matter since HP uses a proprietary debug format.

I believe that the dbx mapping generally corresponds to the ordering
used by HP for fp_int_block_t, __reg32_t and __reg64_t in the save state.
However, the introduction of PA 2.0 made the save state more complex.
See the definition for struct save_state in pa/save_state.h.  Thus,
numbering compatibility with the save state probably isn't as useful
as it once once.

> The gdb numbering scheme seems to be there for a long time. I don't know 
> if this is the way HP numbers registers in their debug format. Does 
> anybody have a pointer to this information?

The current gcc numbering scheme has also been there for a long time.

At the moment, I don't see a reason to change the number scheme anywhere.
It seems that if there is a problem, it's in gdb (dbx vs. dwarf numbers).

Adding unused registers to gcc register tables isn't going to help
performance and it might break exception support if code from two GCC
versions is linked together.  We can define DWARF_FRAME_REGISTERS if
we need more frame registers (e.g., to restore the floating-point
state or 64-bit registers in 32-bit mode).  However, at the moment,
the unwind hooks to do this aren't there.

One bit in gcc bothers me.  If we didn't define DWARF_FRAME_REGNUM
(i.e., used the dbx default), it appears we could map the dbx numbers
to frame numbers using DWARF2_FRAME_REG_OUT.  The two techniques
appear redundant unless we actually need to define DWARF2_FRAME_REG_OUT
to map dbx numbers to frame numbers (i.e., the documentation is
wrong about the numbers being collected using DWARF_FRAME_REGNUM).
In the rs6000 sysv4.h case, DWARF_FRAME_REGNUM is also the gcc hard
registers but it appears that the ABIs mandate numbers for .debug_frame,
so a remapping is needed.  In our case, we don't have an ABI...

> I see that in late 2003/early 2004 there was a discussion about archs 
> with mismatched "dbx register numbers" vs "dwarf CFI register numbers" 
> on gcc@gcc.gnu.org and gdb-patches@gcc.gnu.org. Back then the discussion 
> was about ppc64, although i was not quite sure what was the conclusion 
> of those discussions. hppa64 is in a similar situation.

I guess this was the result:

2004-01-21  Alan Modra  <amodra@bigpond.net.au>

        * config/rs6000/sysv4.h (DWARF2_FRAME_REG_OUT): Define.
	* dwarf2out.c (output_cfi): Map regs using DWARF2_FRAME_REG_OUT.
	* doc/tm.texi (DWARF_FRAME_REGNUM, DWARF2_FRAME_REG_OUT): Document.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Register numbers on hppa64

[Mark Kettenis]

> Date: Sat, 26 Nov 2005 11:52:34 -0500 (EST)
> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> 
> One bit in gcc bothers me.  If we didn't define DWARF_FRAME_REGNUM
> (i.e., used the dbx default), it appears we could map the dbx numbers
> to frame numbers using DWARF2_FRAME_REG_OUT.  The two techniques
> appear redundant unless we actually need to define DWARF2_FRAME_REG_OUT
> to map dbx numbers to frame numbers (i.e., the documentation is
> wrong about the numbers being collected using DWARF_FRAME_REGNUM).
> In the rs6000 sysv4.h case, DWARF_FRAME_REGNUM is also the gcc hard
> registers but it appears that the ABIs mandate numbers for .debug_frame,
> so a remapping is needed.  In our case, we don't have an ABI...

But we have a de-facto ABI since GCC has been using
DBX_REGISTER_NUMBER for all non-CFI DWARF2 output.  I never noticed
DWARF2_FRAME_REG_OUT before, but it seems to implement a suggestion I
made in the ppc64 discussion.  Now that it's there I really think you
should consider using it for hppa/hppa64 too.  Something like

#define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH) \
  ((FOR_EH) ? (REGNO) : DBX_REGISTER_NUMBER (REGNO)

if pa32-reg.h and pa64-reg.h should be enough.

Meanwhile, I should get busy and implement the necessary support in
gdb to cope with the fact that .debug_frame has a different encoding
than .eh_frame.

Mark

Re: Register numbers on hppa64

[John David Anglin]

> But we have a de-facto ABI since GCC has been using
> DBX_REGISTER_NUMBER for all non-CFI DWARF2 output.  I never noticed
> DWARF2_FRAME_REG_OUT before, but it seems to implement a suggestion I
> made in the ppc64 discussion.  Now that it's there I really think you
> should consider using it for hppa/hppa64 too.  Something like
> 
> #define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH) \
>   ((FOR_EH) ? (REGNO) : DBX_REGISTER_NUMBER (REGNO)
> 
> if pa32-reg.h and pa64-reg.h should be enough.
> 
> Meanwhile, I should get busy and implement the necessary support in
> gdb to cope with the fact that .debug_frame has a different encoding
> than .eh_frame.

Let me understand, are you saying that .debug_frame has a mix
of gcc and dbx register numbers at present (i.e., it contains
both cfi and non-cfi data)?  If that's the case and it's hard
for gdb to tell the difference, then I agree that we should
make the above change.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Register numbers on hppa64

[Mark Kettenis]

> Date: Sat, 26 Nov 2005 12:52:25 -0500 (EST)
> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>
> > But we have a de-facto ABI since GCC has been using
> > DBX_REGISTER_NUMBER for all non-CFI DWARF2 output.  I never noticed
> > DWARF2_FRAME_REG_OUT before, but it seems to implement a suggestion I
> > made in the ppc64 discussion.  Now that it's there I really think you
> > should consider using it for hppa/hppa64 too.  Something like
> > 
> > #define DWARF2_FRAME_REG_OUT(REGNO, FOR_EH) \
> >   ((FOR_EH) ? (REGNO) : DBX_REGISTER_NUMBER (REGNO)
> > 
> > if pa32-reg.h and pa64-reg.h should be enough.
> > 
> > Meanwhile, I should get busy and implement the necessary support in
> > gdb to cope with the fact that .debug_frame has a different encoding
> > than .eh_frame.
> 
> Let me understand, are you saying that .debug_frame has a mix
> of gcc and dbx register numbers at present (i.e., it contains
> both cfi and non-cfi data)?  If that's the case and it's hard
> for gdb to tell the difference, then I agree that we should
> make the above change.

No what I'm saying is that .dwarf_frame uses different register
numbers than .debug_info and other .debug_xxx sections.  This is
awkward and confusing because the same DWARF operations that refer to
register numbers are used in both sections but suddenly have a
different meaning.

Mark

Re: Register numbers on hppa64

[John David Anglin]

> No what I'm saying is that .dwarf_frame uses different register
> numbers than .debug_info and other .debug_xxx sections.  This is
> awkward and confusing because the same DWARF operations that refer to
> register numbers are used in both sections but suddenly have a
> different meaning.

Ok.

If we change the register use in .dwarf_frame, then we are breaking
compatibility with previously compiled code.  This isn't a big deal
under HP-UX (dwarf debugging was totally broken on hppa64 until a
recent assembler fix).  However, there is a fair bit of installed
code running linux.  Thus, I would say not change the status quo
if the above confusion can be handled.  The actual numbers used for
the FP registers are obscure and I doubt many people actually care
what they are.  It's only people maintaining the dwarf code that
are likely to get confused.  If readelf produced a text rather than
numeric representation, then the problem would largely go away.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Register numbers on hppa64

[Randolph Chung]

> If we change the register use in .dwarf_frame, then we are breaking
> compatibility with previously compiled code.  This isn't a big deal
> under HP-UX (dwarf debugging was totally broken on hppa64 until a
> recent assembler fix).  However, there is a fair bit of installed
> code running linux.  Thus, I would say not change the status quo
> if the above confusion can be handled.  The actual numbers used for
> the FP registers are obscure and I doubt many people actually care
> what they are.  It's only people maintaining the dwarf code that
> are likely to get confused.  If readelf produced a text rather than
> numeric representation, then the problem would largely go away.

If I understand Mark correctly, the suggestion would change the 
numbering used for dwarf cfi/eh, but not the register numbers emitted 
for .debug_info, right?

FWIW currently on hppa-linux, gdb does not use dwarf cfi for frame 
unwinding. It's on my list of things to do, but if something need 
changing in gcc for whatever reason, now is a good time to do it as far 
as I'm concerned.

randolph

Re: Register numbers on hppa64

[John David Anglin]

> > If we change the register use in .dwarf_frame, then we are breaking
> > compatibility with previously compiled code.  This isn't a big deal
> > under HP-UX (dwarf debugging was totally broken on hppa64 until a
> > recent assembler fix).  However, there is a fair bit of installed
> > code running linux.  Thus, I would say not change the status quo
> > if the above confusion can be handled.  The actual numbers used for
> > the FP registers are obscure and I doubt many people actually care
> > what they are.  It's only people maintaining the dwarf code that
> > are likely to get confused.  If readelf produced a text rather than
> > numeric representation, then the problem would largely go away.
> 
> If I understand Mark correctly, the suggestion would change the 
> numbering used for dwarf cfi/eh, but not the register numbers emitted 
> for .debug_info, right?

It would change the numbering in .debug_frame but not .eh_frame
if I understand correctly.  We could change to dbx numbers everwhere
but that would have a much more significant on the ABI and make the
frame tables for unwinding much larger.  The positive side is that
it would allow recording more information in the frame state if
required.

> FWIW currently on hppa-linux, gdb does not use dwarf cfi for frame 
> unwinding. It's on my list of things to do, but if something need 
> changing in gcc for whatever reason, now is a good time to do it as far 
> as I'm concerned.

That certainly would provide a test as to whether we are providing
the correct call frame information in all cases.  I guess there may
be problems with unwinding through signal frames with really old
kernels.

I'm still not convinced that the numbers in gcc need changing.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: Register numbers on hppa64

[Mark Kettenis]

> Date: Sun, 27 Nov 2005 23:07:16 +0800
> From: Randolph Chung <randolph@tausq.org>
> 
> > If we change the register use in .dwarf_frame, then we are breaking
> > compatibility with previously compiled code.  This isn't a big deal
> > under HP-UX (dwarf debugging was totally broken on hppa64 until a
> > recent assembler fix).  However, there is a fair bit of installed
> > code running linux.  Thus, I would say not change the status quo
> > if the above confusion can be handled.  The actual numbers used for
> > the FP registers are obscure and I doubt many people actually care
> > what they are.  It's only people maintaining the dwarf code that
> > are likely to get confused.  If readelf produced a text rather than
> > numeric representation, then the problem would largely go away.
> 
> If I understand Mark correctly, the suggestion would change the 
> numbering used for dwarf cfi/eh, but not the register numbers emitted 
> for .debug_info, right?

Sorry no.  I propose to use DWARF2_FRAME_REG_OUT() on hppa and hppa32
to change the register numbers for .dwarf_frame to match the ones in
.dwarf_info for ages, and leave .eh_frame alone.  We can't change the
numbers in .eh_frame because that will break binary compatibility for
(C++) exception handling.  It's really silly for .dwarf_info and
.dwarf_frame to use different register numbers.  The fact that on hppa
there is no ABI that defines these register numbers doesn't really
change the argument I made for powerpc.

> FWIW currently on hppa-linux, gdb does not use dwarf cfi for frame 
> unwinding. It's on my list of things to do, but if something need 
> changing in gcc for whatever reason, now is a good time to do it as far 
> as I'm concerned.

Indeed, so the impact of changing the register numbers should be
small.  In addition it doesn't affect the integer registers.  Some
people might have old object modules around that contain the wrong
register numbers, but they'll only affect floating-point registers
which probably don't show up in CFI a lot anyway.

Mark