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. Release: gcc version 3.0.1 20010729 Environment: gnu/linux for PowerPC (Yellow Dog 1.2.1) 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; }
Responsible-Changed-From-To: unassigned->geoffk Responsible-Changed-Why: ppc maintainer
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>
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.
State-Changed-From-To: open->feedback State-Changed-Why: Mattias, you wanted to check this with 3.1. Is there any news on this report? Thanks Wolfgang
State-Changed-From-To: feedback->analyzed State-Changed-Why: Still same behavior. Thanks for the feedback, W.
From: "=?ISO-8859-1?Q?Mattias Engdeg=E5rd?=" <mattias@virtutech.se> To: bangerth@dealii.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, geoffk@gcc.gnu.org, mattias@virtutech.se, gcc-gnats@gcc.gnu.org Cc: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, geoffk@gcc.gnu.org Subject: Re: target/3920: [PPC] wrong register number for CTR in stabs Date: Mon, 13 Jan 2003 10:56:12 +0100 Gcc 3.2.1 behaves identically to 3.0.1 in this respect: I cannot get gcc to emit Stabs/DWARF info saying that a variable lives in CTR, so even if gcc has the wrong number for it, this has no ill effect. Even if a variable lives in CTR inside a loop, the Stabs/DWARF will have it in some general integer register instead. The latter is a quality-of-debug-info bug.
This should work now for DWARF, so only stabs uses strange numbering.
The stabs numbering should probably match whatever AIX does.
There hasn't been any progress or activity on this bug in 10 years. Is it still a problem with a recent GCC or can the bug be closed?
Stabs is rather obsolete and I don't personally care about it any more. As far as I can tell from the source (GCC 5.3 and GDB 7.10), the problem (wrong CTR numbering in stabs) is still there, but if it were up to me I wouldn't waste any time on it.
Thanks for your response. Let me close this as won't fix then.