Re: target/3920: wrong register number for CTR in stabs

Re: target/3920: wrong register number for CTR in stabs

[rth]

Synopsis: wrong register number for CTR in stabs

Responsible-Changed-From-To: unassigned->geoffk
Responsible-Changed-By: rth
Responsible-Changed-When: Thu Jun 20 16:54:28 2002
Responsible-Changed-Why:
    ppc maintainer

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3920

Re: target/3920: wrong register number for CTR in stabs

[Mattias Engdegård]

The following reply was made to PR target/3920; it has been noted by GNATS.

From: "=?ISO-8859-1?Q?Mattias Engdeg=E5rd?=" <mattias@virtutech.se>
To: geoffk@redhat.com
Cc: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   geoffk@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/3920: wrong register number for CTR in stabs
Date: Mon, 24 Jun 2002 12:02:53 +0200

 >Why do you think this is incorrect?  The assembler code generated by
 >GCC 3.1 with -O2 -g -mregnames is:
 [...]
 >.L9:
 >        add %r0,%r0,%r3
 >        addi %r3,%r3,-1
 >        bdnz .L9
 
 You are right of course. Gcc 2.95 didn't use an integer register that
 worked in parallel with CTR and would instead do a mfctr in the loop
 (which is less efficient of course), so I was confused in my reporting.
 Sorry about that.
 
 A better example would be
 
 int sum(int n)
 {
         int i, j = 0, s = 0;
         for(i = n; i != 0; i--) {
 		s += j;
 		j *= 2;
 	}
         return s;
 }
 
 the loop of which gcc 3.0.2 (I didn't have 3.1 handy) turns into the nice code
 
 .L8:
         add %r3,%r3,%r0
         slwi %r0,%r0,1
         bdnz .L8
 
 but where the stabs claim 'i' lives in register 66, which does not make sense
 for CTR. The DWARF2 output (compiling with -gdwarf-2) seems to use the same
 incorrect numbering.
 
 I will check 3.1 as soon as I have built it.
 

Re: target/3920: wrong register number for CTR in stabs

[Geoff Keating]

The following reply was made to PR target/3920; it has been noted by GNATS.

From: Geoff Keating <geoffk@geoffk.org>
To: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   geoffk@gcc.gnu.org, mattias@virtutech.se, nobody@gcc.gnu.org,
   gcc-gnats@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, mattias@virtutech.se,
   nobody@gcc.gnu.org
Subject: Re: target/3920: wrong register number for CTR in stabs
Date: Thu, 20 Jun 2002 22:30:37 -0700

 > Date: 20 Jun 2002 23:54:29 -0000
 > From: rth@gcc.gnu.org
 > Reply-To: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
 >    geoffk@gcc.gnu.org, mattias@virtutech.se, nobody@gcc.gnu.org,
 >    gcc-gnats@gcc.gnu.org
 
 > In gcc 3.0.1 it emits RSYM with an integer register
 > (r3, in this case)
 
 Why do you think this is incorrect?  The assembler code generated by
 GCC 3.1 with -O2 -g -mregnames is:
 
 sum:
 .LFB1:  
         .loc 1 2 0
         .loc 1 4 0
 .LBB2:  
         mr. %r3,%r3
         .loc 1 3 0
         li %r0,0
         .loc 1 4 0
         beq- %cr0,.L8
         mtctr %r3
 .L9:
         .loc 1 5 0
         add %r0,%r0,%r3
         .loc 1 4 0
         addi %r3,%r3,-1
         bdnz .L9
 .L8:
         .loc 1 7 0
 .LBE2:  
         mr %r3,%r0
         blr
 
 The DWARF2 output (powerpc GCC switched from stabs to dwarf2 as of
 3.1) has:
 
         .uleb128 0x2     # (DIE (0x25) DW_TAG_subprogram)
         .4byte  0x62     # DW_AT_sibling
         .byte   0x1      # DW_AT_external
         .ascii "sum\0"   # DW_AT_name
         .byte   0x1      # DW_AT_decl_file
         .byte   0x2      # DW_AT_decl_line
         .byte   0x1      # DW_AT_prototyped
         .4byte  0x62     # DW_AT_type
         .4byte  .LFB1    # DW_AT_low_pc
         .4byte  .LFE1    # DW_AT_high_pc
         .byte   0x1      # DW_AT_frame_base
         .byte   0x51     # DW_OP_reg1
         .uleb128 0x3     # (DIE (0x40) DW_TAG_formal_parameter)
         .ascii "n\0"     # DW_AT_name
         .byte   0x1      # DW_AT_decl_file
         .byte   0x1      # DW_AT_decl_line
         .4byte  0x62     # DW_AT_type
         .byte   0x1      # DW_AT_location
         .byte   0x53     # DW_OP_reg3
         .uleb128 0x4     # (DIE (0x4b) DW_TAG_variable)
         .ascii "i\0"     # DW_AT_name
         .byte   0x1      # DW_AT_decl_file
         .byte   0x3      # DW_AT_decl_line
         .4byte  0x62     # DW_AT_type
         .byte   0x1      # DW_AT_location
         .byte   0x53     # DW_OP_reg3
         .uleb128 0x4     # (DIE (0x56) DW_TAG_variable)
         .ascii "s\0"     # DW_AT_name
         .byte   0x1      # DW_AT_decl_file
         .byte   0x3      # DW_AT_decl_line
         .4byte  0x62     # DW_AT_type
         .byte   0x1      # DW_AT_location
         .byte   0x50     # DW_OP_reg0
         .byte   0x0      # end of children of DIE 0x25
 
 that is, 'i' is in r3, 's' is in r0, and 'n' is in r3, all of which
 seem accurate.
 
 I am unable to come up with an example that shows any register in
 CTR or LR.  CR is a special case, because it isn't very helpful to say
 "oh, this went in the CR"; the debugger probably really wants to know
 which actual CR bits the variable is in.
 
 I do suspect, though, that possibly a DBX_REGISTER_NUMBER definition
 might be a good idea.  I will put it onto my queue.
 
 -- 
 - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

target/3920: wrong register number for CTR in stabs

[mattias]

>Number:         3920
>Category:       target
>Synopsis:       wrong register number for CTR in stabs
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 03 04:46:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     mattias@virtutech.se
>Release:        gcc version 3.0.1 20010729 (prerelease) (powerpc-unknown-linux-gnu)
>Organization:
>Environment:
gnu/linux for PowerPC (Yellow Dog 1.2.1)
>Description:
When a variable is placed in the CTR register, the RSYM
stab emitted contains the wrong register number.
In gcc 3.0.1 it emits RSYM with an integer register
(r3, in this case); in the distribution-supplied
gcc 2.95.2 19991024 (release/franzo), the bogus register
number 66 is emitted.

66 is gcc's internal number for CTR, but gdb expects it to
be 68 (and, to add to the confusion, the SVR ABI claims the
DWARF number for CTR is 109 --- which should be relevant
as gcc seems to use the same numbering for stabs and DWARF).

Other oddball registers like LR and CR also have different
numbers in gcc, gdb and DWARF.
DBX_REGISTER_NUMBER is defined as the identity function
in rs6000.h and that is perhaps incorrect.
>How-To-Repeat:
Compile the following with -O2 -g, and look at the stabs:

int sum(int n)
{
	int i, s = 0;
	for(i = n; i != 0; i--)
		s += i;
	return s;
}
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: