SH5 compact register numbering in gcc -> gdb interface

SH5 compact register numbering in gcc -> gdb interface

[Joern Rennecke]

The numbers currently used to encode registers in the debug information
for SH5compact seem quite arbitrary.  I see that they correspond
to the current pseudo register scheme in gdb, but this is going
to change when a unified interface for SH and SH64 is created.
What I have in mind for the simulator interface is to keep the
current SH1-SH4, SH[3]-DSP register numbers, (and also keep the
corresponding gdb pseudo register numbers), and start the SH64
numbers at 128.
The SHcompact simulator register numbers can be the same as for SH4.
However, this exposes the arbitrariness of the gcc->gdb interface,
and I think now - before the integration of the simulator and gdb
port into the FSF sources - is our last chance to change it.

The SHcompact registers are all mapped to SH5media registers,
and therefore it seems most natural to use the numbers used
for these SH5media registers also in SHcompact code - indeed,
this is currently already done for the general purpose registers.
The only odd one out is MACH, which resides in the upper 32 bit
of R17; for this I propose to use number 141.
This numbering also has the advantage that all SH5compact registers
except MACH can be encoded with LEB128 in a single byte.

compact reg current #   sh5 equiv    proposed #
-----------+-----------+------------+------------------
R0  .. R15     0 ..  15 R0   .. R15    0 ..  15
FR0 .. FR15  245 .. 260 FR0  .. FR15  77 ..  92
XD0 .. XD14  289 .. 296 DR16 .. DR30  93 .. 107 (odd only)
PR           241        R18           18
T            242        R19           19
GBR          238        R16           16
MACH         239        R17(high)    141
MACL         240        R17(low)      17
FPUL         244        FR32         109

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Joern Rennecke]

> compact reg current #   sh5 equiv    proposed #
> -----------+-----------+------------+------------------
> T            242        R19           19
> GBR          238        R16           16

P.S.:
SH[1-4] gcc and gdb currently disagree about the meaning of
numbers 18 and 19.
   gcc gdb
17 t   gbr
18 gbr vbr

This shouldn't really matter since these registers should
not appear in debug information with the ABIs currently
in use.  It is confusing, however, that gcc pretends that
this is part of the interface.  I therefore propose to remove
mappings for T and GDB from SH_DBX_REGISTER_NUMBER.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Elena Zannoni]

Joern Rennecke writes:
 > > compact reg current #   sh5 equiv    proposed #
 > > -----------+-----------+------------+------------------
 > > T            242        R19           19
 > > GBR          238        R16           16
 > 
 > P.S.:
 > SH[1-4] gcc and gdb currently disagree about the meaning of
 > numbers 18 and 19.
 >    gcc gdb
 > 17 t   gbr
 > 18 gbr vbr
 > 

This can be worked around in gdb with
STAB_REG_TO_REGNUM/DWARF2_REG_TO_REGNUM functions. Other targets do
this.

 > This shouldn't really matter since these registers should
 > not appear in debug information with the ABIs currently
 > in use.  It is confusing, however, that gcc pretends that
 > this is part of the interface.  I therefore propose to remove
 > mappings for T and GDB from SH_DBX_REGISTER_NUMBER.

I am not sure I understand your last sentence. You want to remove T
from the mapping? It is not strictly necessary.

Elena


 > 	
 > -- 
 > --------------------------
 > SuperH
 > 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
 > T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Joern Rennecke]

ezannoni@redhat.com wrote:
> This can be worked around in gdb with
> STAB_REG_TO_REGNUM/DWARF2_REG_TO_REGNUM functions. Other targets do
> this.

OK, but I see no point in setting up such a mapping when there is
no data it would operate on.
	
>  > This shouldn't really matter since these registers should
>  > not appear in debug information with the ABIs currently
>  > in use.  It is confusing, however, that gcc pretends that
>  > this is part of the interface.  I therefore propose to remove
>  > mappings for T and GDB from SH_DBX_REGISTER_NUMBER.
> 
> I am not sure I understand your last sentence. You want to remove T
> from the mapping? It is not strictly necessary.

The presense of T and gdb in the mapping is just confusing, since there
is no interface for these registers between gcc and gdb at the present,
and no reason for it to be.  If we ever think we have to put a user variable
into T and/or gbr, and express this in debug information, we can still pick
a number, and make it consistent between gcc and gdb at the same time.

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Elena Zannoni]

Joern Rennecke writes:
 > The numbers currently used to encode registers in the debug information
 > for SH5compact seem quite arbitrary.  I see that they correspond
 > to the current pseudo register scheme in gdb, but this is going
 > to change when a unified interface for SH and SH64 is created.
 > What I have in mind for the simulator interface is to keep the
 > current SH1-SH4, SH[3]-DSP register numbers, (and also keep the
 > corresponding gdb pseudo register numbers), and start the SH64
 > numbers at 128.
 > The SHcompact simulator register numbers can be the same as for SH4.
 > However, this exposes the arbitrariness of the gcc->gdb interface,
 > and I think now - before the integration of the simulator and gdb
 > port into the FSF sources - is our last chance to change it.
 > 

Hmmm, in theory the numbers in the debug info for sh5 don't need to be
the same as the gdb ones. In theory GDB could deal with this by defining
its own mapping with the macro DWARF2_REG_TO_REGNUM.

However this is only a piece of the puzzle... see below

 > The SHcompact registers are all mapped to SH5media registers,
 > and therefore it seems most natural to use the numbers used
 > for these SH5media registers also in SHcompact code - indeed,
 > this is currently already done for the general purpose registers.
 > The only odd one out is MACH, which resides in the upper 32 bit
 > of R17; for this I propose to use number 141.
 > This numbering also has the advantage that all SH5compact registers
 > except MACH can be encoded with LEB128 in a single byte.
 > 
 > compact reg current #   sh5 equiv    proposed #
 > -----------+-----------+------------+------------------
 > R0  .. R15     0 ..  15 R0   .. R15    0 ..  15
 > FR0 .. FR15  245 .. 260 FR0  .. FR15  77 ..  92
 > XD0 .. XD14  289 .. 296 DR16 .. DR30  93 .. 107 (odd only)
 > PR           241        R18           18
 > T            242        R19           19
 > GBR          238        R16           16
 > MACH         239        R17(high)    141
 > MACL         240        R17(low)      17
 > FPUL         244        FR32         109
 > 

If you change the compact registers numbers in the debug info to be
the same as the (or to reuse) numbers for sh media, then the gdb port
will be badly broken. (Never mind for the moment that the current
mapping is screwed up, I agree, but for opposite reasons to
yours...I'll explain in a second.)  The reason that the gdb port will
break is that gdb needs to know the ABI currently in use when
reading or writing a register, because the register sizes are
different. For this reason GDB relies on the the register numbers
being disjoint for compact and media modes.

Now, looking at the current mapping, the 2 sets are not disjoint, and
this is the reason for which gdb is failing some tests currently. I
hadn't closely looked at this mapping before, unfortunately.  In case
of general registers gdb gets very confused between compact and media
mode. It doesn't know how long the register is when trying to read the
value of a variable stored in a general register because the debug
information is exactly the same for the 2 modes. The only way to get
around this, which your re-mapping would also require, is to have
*always* available the PC of the frame relative to which we are
reading the register, because the PC being odd/even tells us which
ABI, and therefore which register size, is in use.  At this time I
have identified 2 places in GDB where I have a hack in place to work
around this overlap of register sets. However I haven't submitted the
hacks publicly, because they are pretty bad. Anyway, there are plenty
of other places where a PC value (i.e. a frame parameter) would need
to be added to gdb internal functions, to get this right. 

As far as the sh-tdep.c code goes, this also would have to be
extensively rewritten if the assumption that the register sets are
disjoint is dropped.

So, I would be opposed to such a change.

I don't think renumbering the simulator registers would have such a
devastating effect.

Anyway, I agree with you that the current version of the
SH_DBX_REGISTER_NUMBER is not the most logic arrangement.  The
floating point registers are mapped to a separate subset, but the
general registers are not. 

All the following registers should be mapped to a register
set disjoint from the sh media one.
Right now they are not.

SH COMPACT MODE (ISA 16)
221     r0_c, r1_c, r2_c,  r3_c,  r4_c,  r5_c,  r6_c,  r7_c,
229     r8_c, r9_c, r10_c, r11_c, r12_c, r13_c, r14_c, r15_c,
237     pc_c,
238     gbr_c, mach_c, macl_c, pr_c, t_c,
243     fpscr_c, fpul_c,
245     fr0_c, fr1_c, fr2_c,  fr3_c,  fr4_c,  fr5_c,  fr6_c,  fr7_c,
253     fr8_c, fr9_c, fr10_c, fr11_c, fr12_c, fr13_c, fr14_c, fr15_c
261     dr0_c, dr2_c, dr4_c,  dr6_c,  dr8_c,  dr10_c, dr12_c, dr14_c
269     fv0_c, fv4_c, fv8_c,  fv12_c

I believe something like this would work.

Elena


Index: sh.h
===================================================================
RCS file: /cvs/uberbaum/gcc/config/sh/sh.h,v
retrieving revision 1.137
diff -u -r1.137 sh.h
--- sh.h	3 Mar 2002 21:10:04 -0000	1.137
+++ sh.h	2 May 2002 00:49:21 -0000
@@ -2896,6 +2896,8 @@
 #define DBX_REGISTER_NUMBER(REGNO) \
   (GENERAL_REGISTER_P (REGNO) \
    ? ((REGNO) - FIRST_GENERAL_REG) \
+   ? ((REGNO) - FIRST_GENERAL_REG + (TARGET_SH5 ? (TARGET_SHCOMPACT ? 221 \
+                                                   : 0) : 0)) \
    : FP_REGISTER_P (REGNO) \
    ? ((REGNO) - FIRST_FP_REG + (TARGET_SH5 ? (TARGET_SHCOMPACT ? 245 \
 					      : 77) : 25)) \

Re: SH5 compact register numbering in gcc -> gdb interface

[Joern Rennecke]

ezannoni@redhat.com wrote:
> Now, looking at the current mapping, the 2 sets are not disjoint, and
> this is the reason for which gdb is failing some tests currently. I
> hadn't closely looked at this mapping before, unfortunately.  In case
> of general registers gdb gets very confused between compact and media
> mode. It doesn't know how long the register is when trying to read the
> value of a variable stored in a general register because the debug
> information is exactly the same for the 2 modes. The only way to get
> around this, which your re-mapping would also require, is to have
> *always* available the PC of the frame relative to which we are
> reading the register, because the PC being odd/even tells us which
> ABI, and therefore which register size, is in use.  At this time I
> have identified 2 places in GDB where I have a hack in place to work
> around this overlap of register sets. However I haven't submitted the
> hacks publicly, because they are pretty bad. Anyway, there are plenty
> of other places where a PC value (i.e. a frame parameter) would need
> to be added to gdb internal functions, to get this right.

Right, so we do need the general purpose register to have different
numbers, because of their different size.  The size shouldn't really
matter for single integer values inside a register, but it does when you
need more than one register for SHcompact, or you are describing register
saves / restores.

> As far as the sh-tdep.c code goes, this also would have to be
> extensively rewritten if the assumption that the register sets are
> disjoint is dropped.
> 
> So, I would be opposed to such a change.

It needs to be extensively rewritten anyways to accomodate the disjoint
register numbers for SH1-4 / SHmedia simulators, and to fix numerous bugs.
This rewrite becomes indeed simpler if we make the interface a bit more
straightforward.

> I don't think renumbering the simulator registers would have such a
> devastating effect.

sh-tdep has a lot of hardcoded 'knowledge' how simulator numbers relate
to the layout of th register cache.  Moreover, we should loose all the
tdep->FOO_REGNUM stuff where the value is actually a constant according
to the simulator interface.

> Anyway, I agree with you that the current version of the
> SH_DBX_REGISTER_NUMBER is not the most logic arrangement.  The
> floating point registers are mapped to a separate subset, but the
> general registers are not.
> 
> All the following registers should be mapped to a register
> set disjoint from the sh media one.
> Right now they are not.
> 
> SH COMPACT MODE (ISA 16)
> 221     r0_c, r1_c, r2_c,  r3_c,  r4_c,  r5_c,  r6_c,  r7_c,
> 229     r8_c, r9_c, r10_c, r11_c, r12_c, r13_c, r14_c, r15_c,
> 237     pc_c,
> 238     gbr_c, mach_c, macl_c, pr_c, t_c,
> 243     fpscr_c, fpul_c,
> 245     fr0_c, fr1_c, fr2_c,  fr3_c,  fr4_c,  fr5_c,  fr6_c,  fr7_c,
> 253     fr8_c, fr9_c, fr10_c, fr11_c, fr12_c, fr13_c, fr14_c, fr15_c
> 261     dr0_c, dr2_c, dr4_c,  dr6_c,  dr8_c,  dr10_c, dr12_c, dr14_c
> 269     fv0_c, fv4_c, fv8_c,  fv12_c

fr0 .. fr15 are really the same in SHcompact and SHmedia, so there is no
reason to use different numbers in the gcc -> gdb interface.  It is convenient
to have different numbers in the gtdb <-> sim interface since that allows
you to keep the old numbers for SH1-SH4, while having contigous numbers
for fr0..fr63 for SHmedia.
dr0..dr14 / fv0 .. fv12 don't even exist as separate registers, but are
just a different view of fv0..fv15.  There is no reason to make them part
of the gcc -> gdb or gdb <-> sim interface, nor is there any point in
providing disjoint pseudo registers for media and compact mode in gdb itself.

PC, T, GBR and FPSCR are not actually in the gcc -> gdb interface.
If you wanted to put a value into T_C, this can be described as
putting it into R19, so there so no point in even reserving a number.
I can imagine circumstances where you would want to push GBR or
FPSCR in the prologue, so it might make sense to have a number for them.

FPUL is the same size as FR32, so it makes sense to describe it as FR32,
since that is what it really is.

PR would only appear as a saved register, but I gather that gdb needs to know
the size it has been saved in, so it makes sense to have a separate number.

MACH and MACL are a rather unique problem.  When you put a 64 bit value into
them, you can only describe this properly if you are using big endian.
This could be fixed e,g, by having a third register, i.e.
big endian MACH / MACL / little endian MACH.

 19     t_c

 77     fr0, fr1, fr2,  fr3,  fr4,  fr5,  fr6,  fr7,
 85     fr8, fr9, fr10, fr11, fr12, fr13, fr14, fr15,
 93     xf0, xf1, xf2,  xf3,  xf4,  xf5,  xf6,  xf7,
101     xf8, xf9, xf10, xf11, xf12, xf13, xf14, xf15,
109     fpul_c
	
141     r0_c, r1_c, r2_c,  r3_c,  r4_c,  r5_c,  r6_c,  r7_c,
149     r8_c, r9_c, r10_c, r11_c, r12_c, r13_c, r14_c, r15_c,
157     gbr_c, mach_c (big endian), macl_c, mach_c (little endian), pr_c,
fpscr_c	
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Alexandre Oliva]

On May  2, 2002, Joern Rennecke <joern.rennecke@st.com> wrote:

> Right, so we do need the general purpose register to have different
> numbers, because of their different size.  The size shouldn't really
> matter for single integer values inside a register, but it does when you
> need more than one register for SHcompact, or you are describing register
> saves / restores.

The register numbering used by GCC is definitely arbitrary.  I hadn't
even considered there might be reasons for it not to be, for which I
apologize.  It's a bit unfortunate that this has come up when we're
this close to the first GCC release to include the SH5 port.  I'm not
sure we have enough time to come up with a solution, nor whether Mark
would accept it in the branch.  It would be too bad if GDB couldn't
debug code compiled by GCC 3.1.  Perhaps we can come up with a
backward-compatible register mapping, even if GDB would work in a
degraded mode when the current register numbering is in use.

> I can imagine circumstances where you would want to push GBR or
> FPSCR in the prologue, so it might make sense to have a number for them.

Especially if we move to some more efficient exception handling
mechanism.  But there are going to be other interesting problems to
solve to be able to do it.  I don't think the current infrastructure
can handle registers saved with different sizes in the stack (think
SHmedia calls SHcompact calls SHmedia, such that we have to restore
say r10 from the SHcompact frame, in which it was saved as a 32-bit
value).

> FPUL is the same size as FR32, so it makes sense to describe it as FR32,
> since that is what it really is.

> PR would only appear as a saved register, but I gather that gdb needs to know
> the size it has been saved in, so it makes sense to have a separate number.

Agreed.

> MACH and MACL are a rather unique problem.  When you put a 64 bit value into
> them, you can only describe this properly if you are using big endian.
> This could be fixed e,g, by having a third register, i.e.
> big endian MACH / MACL / little endian MACH.

Sounds like a reasonable solution.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: SH5 compact register numbering in gcc -> gdb interface

[Joern Rennecke]

aoliva@redhat.com wrote:
> The register numbering used by GCC is definitely arbitrary.  I hadn't
> even considered there might be reasons for it not to be, for which I
> apologize.  It's a bit unfortunate that this has come up when we're
> this close to the first GCC release to include the SH5 port.  I'm not
> sure we have enough time to come up with a solution, nor whether Mark
> would accept it in the branch.  It would be too bad if GDB couldn't
> debug code compiled by GCC 3.1.  Perhaps we can come up with a
> backward-compatible register mapping, even if GDB would work in a
> degraded mode when the current register numbering is in use.

I was proposing only to change the SHcompact mapping, so that code
compiled with the default options won't be affected.  Moreover, there
are still a number of bugs in gcc 3.1 that affect the SH5 port, some
of which can only be fixed with changes to the machine-independent sources.
I am working on this, but it is not feasible to finish this work in time
for gcc 3.1 .  Hence, I'd expect some gcc 3.2 snapshots to be better
for SH5 than gcc 3.1 for production code.

Another reason to switch to a post 3.1 compiler will be debugging speed.
The prologue-disassembling slows backtraces considerably when debugging
on real hardware.  We are currently working on SH gcc emitting proper
cfi information, and gdb making use of it.  For SH4 this has already
proved to make quite an improvement, and the gcc bug fixes for this
are among the next patches I intend to put into the FSF gcc repository.

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Andrew Cagney]

> 
> I was proposing only to change the SHcompact mapping, so that code
> compiled with the default options won't be affected.  Moreover, there
> are still a number of bugs in gcc 3.1 that affect the SH5 port, some
> of which can only be fixed with changes to the machine-independent sources.
> I am working on this, but it is not feasible to finish this work in time
> for gcc 3.1 .  Hence, I'd expect some gcc 3.2 snapshots to be better
> for SH5 than gcc 3.1 for production code.
> 
> Another reason to switch to a post 3.1 compiler will be debugging speed.
> The prologue-disassembling slows backtraces considerably when debugging
> on real hardware.  We are currently working on SH gcc emitting proper
> cfi information, and gdb making use of it.  For SH4 this has already
> proved to make quite an improvement, and the gcc bug fixes for this
> are among the next patches I intend to put into the FSF gcc repository.

Humor me here.

How do you use dwarf2 cfi to unwind a compact register (saved on the 
stack) back to a media register?  In addition to the address of the 
saved register you'll need to know that only part of the register was 
saved. Does CFI describe this?

Andrew

Re: SH5 compact register numbering in gcc -> gdb interface

[Joern Rennecke]

ac131313@cygnus.com wrote:
> Humor me here.
> 
> How do you use dwarf2 cfi to unwind a compact register (saved on the
> stack) back to a media register?  In addition to the address of the
> saved register you'll need to know that only part of the register was
> saved. Does CFI describe this?

With the proposed numbering change (2nd revision), we get different
numbers to describe compact an media registers.  So when only the lower
32 bits are saved, gcc can use the SHcompact register number to describe
this.

N.B., the upper 32 bits of the register are actually overwritten in the
process.  The restore from the stack sign-extends from bit 31.  The caller
is responsible to make sure that no 64 bit value is live in the register.	

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Elena Zannoni]

Joern Rennecke writes:
 > ac131313@cygnus.com wrote:
 > > Humor me here.
 > > 
 > > How do you use dwarf2 cfi to unwind a compact register (saved on the
 > > stack) back to a media register?  In addition to the address of the
 > > saved register you'll need to know that only part of the register was
 > > saved. Does CFI describe this?
 > 
 > With the proposed numbering change (2nd revision), we get different
 > numbers to describe compact an media registers.  So when only the lower
 > 32 bits are saved, gcc can use the SHcompact register number to describe
 > this.
 > 
 > N.B., the upper 32 bits of the register are actually overwritten in the
 > process.  The restore from the stack sign-extends from bit 31.  The caller
 > is responsible to make sure that no 64 bit value is live in the register.	

Yes. We seem to agree on the register numbering scheme.

Elena

 > 
 > -- 
 > --------------------------
 > SuperH
 > 2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
 > T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Andrew Cagney]

> ac131313@cygnus.com wrote:
> 
>> Humor me here.
>> 
>> How do you use dwarf2 cfi to unwind a compact register (saved on the
>> stack) back to a media register?  In addition to the address of the
>> saved register you'll need to know that only part of the register was
>> saved. Does CFI describe this?
> 
> 
> With the proposed numbering change (2nd revision), we get different
> numbers to describe compact an media registers.  So when only the lower
> 32 bits are saved, gcc can use the SHcompact register number to describe
> this.

Ok.

> N.B., the upper 32 bits of the register are actually overwritten in the
> process.  The restore from the stack sign-extends from bit 31.  The caller
> is responsible to make sure that no 64 bit value is live in the register.	

This is the bit that I'm still missing.  As far as I know dwarf2cfi 
doesn't have stuff to indicate ``sign-extend''.  I guess this would 
still be handled by GDB magic?  (this is what the existing sh5 code 
appears to do.)

enjoy,
Andrew

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Joern Rennecke]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

To give gcc and gdb a common interface, it is best put into a header file that
but
gdb/sh-tdep and gcc/config/sh/sh.h (can) include.

I thought of putting it into include/elg/sh.h, since elf is now the predominant
object format for SH gcc.  Or should we start something like an include/dwarf
directory?
But then, it's not strictly dwarf either, since these register numbers are
also used for stabs debugging info (in the SH1..SH4 coff toolchain, or if
you ask specifically for stabs.)

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

[-- Attachment #2: sh-debug --]
[-- Type: text/plain, Size: 1014 bytes --]

*** ../include/elf/sh.h-feb8	Fri Feb  8 05:05:58 2002
--- ../include/elf/sh.h	Thu May  9 22:22:18 2002
*************** START_RELOC_NUMBERS (elf_sh_reloc_type)
*** 218,221 ****
--- 218,247 ----
    RELOC_NUMBER (R_SH_64_PCREL, 255)
  END_RELOC_NUMBERS (R_SH_max)
  
+ enum
+ {
+   SH_DEBUG_INFO_R0 = 0,
+   SH_DEBUG_INFO_PR = 17,
+   SH_DEBUG_INFO_GBR = 18,
+   SH_DEBUG_INFO_MACH_BIG = 20, SH_DEBUG_INFO_MACL, SH_DEBUG_INFO_MACH_LITTLE,
+   SH_DEBUG_INFO_FPUL = 23,
+   SH_DEBUG_INFO_FPSCR = 24,
+   SH_DEBUG_INFO_FR0 = 25,
+   SH_DEBUG_INFO_XD0 = 87
+ }
+ 
+ enum
+ {
+   SH64_DEBUG_INFO_R0 = 0,
+   SH64_DEBUG_INFO_TR0 = 68,
+   SH64_DEBUG_INFO_FR0 = 77,
+   SH64_DEBUG_INFO_T_C = 19,
+   SH64_DEBUG_INFO_XF0_C = SH64_DEBUG_INFO_FR0 + 16,
+   SH64_DEBUG_INFO_FPUL_C = SH64_DEBUG_INFO_FR0 + 32,
+   SH64_DEBUG_INFO_R0_C = 141,
+   SH64_DEBUG_INFO_GBR_C = 157,
+   SH64_DEBUG_INFO_MACH_C_BIG, SH64_DEBUG_INFO_MACL_C,
+   SH64_DEBUG_INFO_MACH_C_LITTLE,
+   SH64_DEBUG_INFO_PR_C, SH_DEBUG_INFO_FPSCR_C
+ };
  #endif

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Elena Zannoni]

Joern Rennecke writes:
 > To give gcc and gdb a common interface, it is best put into a header file that
 > but
 > gdb/sh-tdep and gcc/config/sh/sh.h (can) include.
 > 
 > I thought of putting it into include/elg/sh.h, since elf is now the predominant
 > object format for SH gcc.  Or should we start something like an include/dwarf
 > directory?
 > But then, it's not strictly dwarf either, since these register numbers are
 > also used for stabs debugging info (in the SH1..SH4 coff toolchain, or if
 > you ask specifically for stabs.)
 > 

I think include/gcc-sh64.h or include/gdb-sh64.h could be OK. Would match the
include/sim-sh64.h file.


 > --- ../include/elf/sh.h	Thu May  9 22:22:18 2002
 > *************** START_RELOC_NUMBERS (elf_sh_reloc_type)
 > *** 218,221 ****
 > --- 218,247 ----
 >     RELOC_NUMBER (R_SH_64_PCREL, 255)
 >   END_RELOC_NUMBERS (R_SH_max)
 >   
 > + enum
 > + {
 > +   SH_DEBUG_INFO_R0 = 0,
 > +   SH_DEBUG_INFO_PR = 17,
 > +   SH_DEBUG_INFO_GBR = 18,
 > +   SH_DEBUG_INFO_MACH_BIG = 20, SH_DEBUG_INFO_MACL, SH_DEBUG_INFO_MACH_LITTLE,

This will break gdb. Register 22 ir SR. What are these registers?
Doesn't SH have only mach and macl?

 > +   SH_DEBUG_INFO_FPUL = 23,
 > +   SH_DEBUG_INFO_FPSCR = 24,
 > +   SH_DEBUG_INFO_FR0 = 25,
 > +   SH_DEBUG_INFO_XD0 = 87
 > + }
 > + 
 > + enum
 > + {
 > +   SH64_DEBUG_INFO_R0 = 0,
 > +   SH64_DEBUG_INFO_TR0 = 68,
 > +   SH64_DEBUG_INFO_FR0 = 77,
 > +   SH64_DEBUG_INFO_T_C = 19,
 > +   SH64_DEBUG_INFO_XF0_C = SH64_DEBUG_INFO_FR0 + 16,
 > +   SH64_DEBUG_INFO_FPUL_C = SH64_DEBUG_INFO_FR0 + 32,
 > +   SH64_DEBUG_INFO_R0_C = 141,
 > +   SH64_DEBUG_INFO_GBR_C = 157,
 > +   SH64_DEBUG_INFO_MACH_C_BIG, SH64_DEBUG_INFO_MACL_C,
 > +   SH64_DEBUG_INFO_MACH_C_LITTLE,
 > +   SH64_DEBUG_INFO_PR_C, SH_DEBUG_INFO_FPSCR_C
 > + };
 >   #endif

What is the advantage of reusing media numbers for compact registers?
This also wouldn't work with the current code, because it is assumed
that the register sets are disjoint. I see that you have made disjoint
the GPRs and that is OK because it will fix some bugs. Might as well
make the whole set distinct. Same question as above about the mach/macl
registers applies here.
Can you expand a bit on that?

thanks
Elena

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Andrew Cagney]

> I think include/gcc-sh64.h or include/gdb-sh64.h could be OK. Would match the
> include/sim-sh64.h file.

BTW, GDB has started moving the include/sim-*.h files into 
include/gdb/sim-*.h, but otherwise, yes.

Andrew

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Joern Rennecke]

ezannoni@redhat.com:
> > I think include/gcc-sh64.h or include/gdb-sh64.h could be OK. Would match the
> > include/sim-sh64.h file.

Since we are going to have a file that describes both the SH1-4 and SH64 stuff,
I think it makes more sense to just say gdb-sh.h

ac131313@cygnus.com wrote:
> BTW, GDB has started moving the include/sim-*.h files into
> include/gdb/sim-*.h, but otherwise, yes.

Ok, gdb/gdb-sh.h then.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Andrew Cagney]

> 
> Ok, gdb/gdb-sh.h then.

No. This isn't a GDB interface but rather a GCC interface.  gdb/gcc-sh.h 
is one option.

Andrew

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Joern Rennecke]

ac131313@cygnus.com wrote:
> 
> >
> > Ok, gdb/gdb-sh.h then.
> 
> No. This isn't a GDB interface but rather a GCC interface.  gdb/gcc-sh.h
> is one option.

Well, it is both a gcc and a gdb interface, but include/gdb/gcc-sh.h is
fine with me.  The pathname then refers to both of the programs being 
interfaced.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Joern Rennecke]

ezannoni@redhat.com wrote:
> 
> Joern Rennecke writes:
>  > To give gcc and gdb a common interface, it is best put into a header file that
>  > but
>  > gdb/sh-tdep and gcc/config/sh/sh.h (can) include.
>  >
>  > I thought of putting it into include/elg/sh.h, since elf is now the predominant
>  > object format for SH gcc.  Or should we start something like an include/dwarf
>  > directory?
>  > But then, it's not strictly dwarf either, since these register numbers are
>  > also used for stabs debugging info (in the SH1..SH4 coff toolchain, or if
>  > you ask specifically for stabs.)
>  >
> 
> I think include/gcc-sh64.h or include/gdb-sh64.h could be OK. Would match the
> include/sim-sh64.h file.
> 
>  > --- ../include/elf/sh.h      Thu May  9 22:22:18 2002
>  > *************** START_RELOC_NUMBERS (elf_sh_reloc_type)
>  > *** 218,221 ****
>  > --- 218,247 ----
>  >     RELOC_NUMBER (R_SH_64_PCREL, 255)
>  >   END_RELOC_NUMBERS (R_SH_max)
>  >
>  > + enum
>  > + {
>  > +   SH_DEBUG_INFO_R0 = 0,
>  > +   SH_DEBUG_INFO_PR = 17,
>  > +   SH_DEBUG_INFO_GBR = 18,
>  > +   SH_DEBUG_INFO_MACH_BIG = 20, SH_DEBUG_INFO_MACL, SH_DEBUG_INFO_MACH_LITTLE,
> 
> This will break gdb. Register 22 ir SR. What are these registers?

gcc does not emit debug information for SR - if it was encountered in
DBX_REGISTER_NUMBER, the compiler would abort.  So we don't actually have a
number
allocated in the interface right now, and if we need one, we are free to choose
any.

> Doesn't SH have only mach and macl?

Yes, it has only mach and macl.  But you could hold a 64 bit value in this
register
pair, in which case MACH always holds the high part and MACL holds the low part.
So the idea is to use SH_DEBUG_INFO_MACH_BIG for big endian, and
SH_DEBUG_INFO_MACH_LITTLE for little endian.  This way, it is clear where low
and high
part are.  both SH_DEBUG_INFO_MACH_BIG and SH_DEBUG_INFO_MACH_LITTLE are then
mapped
to gdb's MACH.  Note that SH_DEBUG_INFO_MACH_BIG is the old MACH number, and
SH_DEBUG_INFO_MACL is the old MACL number, so we have full backwards
compatibility.
Having both this backwards compatibility and the ability to represent a 64 bit
value
in MACH/MACL for little endian was the point of using 22 for
SH_DEBUG_INFO_MACH_LITTLE.

>  > +   SH64_DEBUG_INFO_R0 = 0,
>  > +   SH64_DEBUG_INFO_TR0 = 68,
>  > +   SH64_DEBUG_INFO_FR0 = 77,
>  > +   SH64_DEBUG_INFO_T_C = 19,
>  > +   SH64_DEBUG_INFO_XF0_C = SH64_DEBUG_INFO_FR0 + 16,
>  > +   SH64_DEBUG_INFO_FPUL_C = SH64_DEBUG_INFO_FR0 + 32,
>  > +   SH64_DEBUG_INFO_R0_C = 141,
>  > +   SH64_DEBUG_INFO_GBR_C = 157,
>  > +   SH64_DEBUG_INFO_MACH_C_BIG, SH64_DEBUG_INFO_MACL_C,
>  > +   SH64_DEBUG_INFO_MACH_C_LITTLE,
>  > +   SH64_DEBUG_INFO_PR_C, SH_DEBUG_INFO_FPSCR_C
>  > + };
>  >   #endif
> 
> What is the advantage of reusing media numbers for compact registers?

The numbers are reused where the registers are actually identical.  Thus,
there is actually less work for gcc and gdb to encode and decode these
registers.

> This also wouldn't work with the current code, because it is assumed
> that the register sets are disjoint. I see that you have made disjoint

I don't know what you need disjoint registers for, when the size and
location of the register is the same in either mode.  What part of the
code makes assumptions about further disjointness?
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Andrew Cagney]

>  + enum
>>  > + {
>>  > +   SH_DEBUG_INFO_R0 = 0,
>>  > +   SH_DEBUG_INFO_PR = 17,
>>  > +   SH_DEBUG_INFO_GBR = 18,
>>  > +   SH_DEBUG_INFO_MACH_BIG = 20, SH_DEBUG_INFO_MACL, SH_DEBUG_INFO_MACH_LITTLE,
>> 
>> This will break gdb. Register 22 ir SR. What are these registers?
> 
> 
> gcc does not emit debug information for SR - if it was encountered in
> DBX_REGISTER_NUMBER, the compiler would abort.  So we don't actually have a
> number
> allocated in the interface right now, and if we need one, we are free to choose
> any.
> 
> 
>> Doesn't SH have only mach and macl?
> 
> 
> Yes, it has only mach and macl.  But you could hold a 64 bit value in this
> register
> pair, in which case MACH always holds the high part and MACL holds the low part.
> So the idea is to use SH_DEBUG_INFO_MACH_BIG for big endian, and
> SH_DEBUG_INFO_MACH_LITTLE for little endian.  This way, it is clear where low
> and high
> part are.  both SH_DEBUG_INFO_MACH_BIG and SH_DEBUG_INFO_MACH_LITTLE are then
> mapped
> to gdb's MACH.  Note that SH_DEBUG_INFO_MACH_BIG is the old MACH number, and
> SH_DEBUG_INFO_MACL is the old MACL number, so we have full backwards
> compatibility.
> Having both this backwards compatibility and the ability to represent a 64 bit
> value
> in MACH/MACL for little endian was the point of using 22 for
> SH_DEBUG_INFO_MACH_LITTLE.

The correct way to represent a 64 bit value in MACH and MACL is to emit 
a location expression indicating that the value is split across the 
MACL/MACH registers.  GDB currently only handles the simple case of this 
(but hey that is just a bug).  If GCC can't emit this info correctly in 
all cases then I guess GCC also has a bug and that bug also needs to be 
fixed.

enjoy,
Andrew

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Joern Rennecke]

ac131313@cygnus.com wrote:
> The correct way to represent a 64 bit value in MACH and MACL is to emit
> a location expression indicating that the value is split across the
> MACL/MACH registers.  GDB currently only handles the simple case of this
> (but hey that is just a bug).  If GCC can't emit this info correctly in
> all cases then I guess GCC also has a bug and that bug also needs to be
> fixed.

Ok, so we don't need the MACH_LITTLE assignments, nabd make MACH_BIG into MACH
again.  That't leave a gap at 22 for the time being, whereas
SH64_DEBUG_INFO_PR_C and SH_DEBUG_INFO_FPSCR_C will follow immediately after
SH64_DEBUG_INFO_MACL_C .

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface - include/elf/sh.h ?

[Joern Rennecke]

ezannoni@redhat.com wrote:
> What is the advantage of reusing media numbers for compact registers?

P.S.: a further - and maybe actually more important - advantage is that
the debug information is compacter, since register numbers < 128 can be
expressed with a single byte.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Joern Rennecke]

ac131313@cygnus.com wrote:
> Humor me here.
> 
> How do you use dwarf2 cfi to unwind a compact register (saved on the
> stack) back to a media register?  In addition to the address of the
> saved register you'll need to know that only part of the register was
> saved. Does CFI describe this?

P.S.:  It is not trivial to make gcc emit different register numbers
for different sizes, but for prologue cfi, that can be done by
attaching a REG_FRAME_RELATED_EXPR note referring to a different
register number when emitting the prologue.

-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 compact register numbering in gcc -> gdb interface

[Alexandre Oliva]

On May  7, 2002, Joern Rennecke <joern.rennecke@st.com> wrote:

> ac131313@cygnus.com wrote:
>> Humor me here.
>> 
>> How do you use dwarf2 cfi to unwind a compact register (saved on the
>> stack) back to a media register?  In addition to the address of the
>> saved register you'll need to know that only part of the register was
>> saved. Does CFI describe this?

> P.S.:  It is not trivial to make gcc emit different register numbers
> for different sizes, but for prologue cfi, that can be done by
> attaching a REG_FRAME_RELATED_EXPR note referring to a different
> register number when emitting the prologue.

But under this design, if we moved to a more efficient exception
handling mechanism, how would throw() know whether to restore the
SHcompact or the SHmedia register before returning to the exception
landing pad?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

DWARFx ? .debug sections infos.

[phi 4369]

Hi All,

May someone point me where to find the descriptions of some dwarf .debug
section.

In my palinux (-g compiled) kernel I see

.debug_frame 
.debug_pubnames
.debug_aranges
.shstrtab

I'd like to know what we are supposed to find in those sections, and better
where to read about it. The only docco I have so far is a Unix Internat (July
27, 1993) document.

Thanx in adavance.
Phi

Re: DWARFx ? .debug sections infos.

[Lars Brinkhoff]

phi 4369 <phi@hpfrcu81.france.hp.com> writes:
> May someone point me where to find the descriptions of some dwarf .debug
> section.

http://www.eagercon.com/dwarf/dwarf-2.0.0.pdf

> The only docco I have so far is a Unix Internat (July 27, 1993)
> document.

Seems to be the same as the one above.  Isn't it good enough?

-- 
Lars Brinkhoff          http://lars.nocrew.org/     Linux, GCC, PDP-10,
Brinkhoff Consulting    http://www.brinkhoff.se/    HTTP programming

Re: DWARFx ? .debug sections infos.

[phi 4369]

Hi Lars,

> 
> Seems to be the same as the one above.  Isn't it good enough?
> 

Jeez, that's the same but I got the paper one. With the electronic version I
can 'search' then find :-) 

The .debug_pubnames .debug_aranges are well documented at 6. and are used for
quick lookup.


Thanx for the document
Cheers,
Phi

--
mailto:Philippe_Benard@hp.com
WTEC HP-UX kernel debugging tools

Re: DWARFx ? .debug sections infos.

[Petr Sorfa]

Hi,

Actually the latest version is at:

http://www.eagercon.com/dwarf/dwarf3std.htm

This should rather be adhered to.

Petr
> >
> > Seems to be the same as the one above.  Isn't it good enough?
> >
> 
> Jeez, that's the same but I got the paper one. With the electronic version I
> can 'search' then find :-)
> 
> The .debug_pubnames .debug_aranges are well documented at 6. and are used for
> quick lookup.
> 
> Thanx for the document
> Cheers,
> Phi
> 
> --
> mailto:Philippe_Benard@hp.com
> WTEC HP-UX kernel debugging tools

Re: SH5 compact register numbering in gcc -> gdb interface

[Andrew Cagney]

> sh-tdep has a lot of hardcoded 'knowledge' how simulator numbers relate
> to the layout of th register cache.  Moreover, we should loose all the
> tdep->FOO_REGNUM stuff where the value is actually a constant according
> to the simulator interface.

Just FYI, the thing that controls the internal register layout of GDB is 
[currently] the remote protocol.  If you try to wire down GDB's internal 
register numbers to match the simulator, you'll likely break GDB's 
compatibility with existing remote targets.

While this limitation is being worked on, it doesn't affect the GDB <-> 
sim maping - that can already be adjusted independant of the other 
register numbering schema.

enjoy,
Andrew