This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Here is an excerpt from a test program: void f1 () { int alpha; int beta; ... { int alpha; int gamma; ... } ... } My command line is "gcc -gstabs+ -S alpha.c". With gcc 3.3.2, I get these healthy-looking stabs: .LBE2: .size f1, .-f1 .stabs "alpha:(0,1)",128,0,15,-4 .stabs "beta:(0,1)",128,0,16,-8 .stabn 192,0,0,.LBB2-f1 .stabs "alpha:(0,1)",128,0,21,-12 .stabs "gamma:(0,1)",128,0,22,-16 .stabn 192,0,0,.LBB3-f1 .stabn 224,0,0,.LBE3-f1 .stabn 224,0,0,.LBE2-f1 stabn 192 is N_LBRAC, and stabn 224 is N_RBRAC. Each group of local variables is followed by its range. All is well. With gcc HEAD 2003-04-11 03:00:00 UTC, all is still fine: .LBE2: .size f1, .-f1 .stabs "alpha:(0,1)",128,0,15,-4 .stabs "beta:(0,1)",128,0,16,-8 .stabn 192,0,0,.LBB2-f1 .stabs "alpha:(0,1)",128,0,21,-12 .stabs "gamma:(0,1)",128,0,22,-16 .stabn 192,0,0,.LBB3-f1 .stabn 224,0,0,.LBE3-f1 .stabn 224,0,0,.LBE2-f1 With gcc HEAD 2003-04-11 04:30:00 UTC, the stabs are wrong: .size f1, .-f1 .stabs "alpha:(0,1)",128,0,15,-4 .stabs "beta:(0,1)",128,0,16,-8 .stabs "alpha:(0,1)",128,0,21,-12 .stabs "gamma:(0,1)",128,0,22,-16 .stabn 192,0,0,.LBB2-f1 .stabn 224,0,0,.LBE2-f1 One of the N_LBRAC/N_RBRAC pairs has disappeared. And with current gcc, gcc HEAD 2004-02-01 01:34:15 UTC: .size f1, .-f1 .stabs "alpha:(0,1)",128,0,15,-4 .stabs "beta:(0,1)",128,0,16,-8 .stabs "alpha:(0,1)",128,0,21,-12 .stabs "gamma:(0,1)",128,0,22,-16 .stabn 192,0,0,.LBB2-f1 .stabn 224,0,0,.LBE2-f1 This problem came in with this patch: 2003-04-10 Zack Weinberg <zack@codesourcery.com> * c-decl.c (struct binding_level): Add shadowed_tags and function_body; remove this_block, tag_transparent, and subblocks_tag_transparent; update comments. ... 2003-04-10 Zack Weinberg <zack@codesourcery.com> * c-tree.h (struct lang_identifier): Replace global_value, local_value members with symbol_value, tag_value. Kill implicit_decl and limbo_value. ... There are two ChangeLog entries here, but only one patch. This is the same patch that caused PR debug/12267. Per the comments in 12267, I'm assigning it to Zack (or trying to). Attachments to follow.
Created an attachment (id=5633) [edit] Source code with nested scopes. Compile with gcc -S -gstabs+.
Created an attachment (id=5634) [edit] Generated assembly code, good, gcc 3.3.2 -S -gstabs+
Created an attachment (id=5635) [edit] Generated assembly code, bad, gcc HEAD 2004-02-01 -gstabs+ -S
Confirmed.
fixed the mime types of all the attachments. sorry for the noise.
Subject: Re: [3.4/3.5 regression] incorrect stabs for nested local variables > fixed the mime types of all the attachments. sorry for the noise. Woops, sorry for the un-useful mime types. I was letting them be set automatically. In the future I will set them explicitly to text/plain. Michael C
Given that stabs are only used on a few platforms by deafult, and that Zack doesn't think this easy to fix for 3.4.0, I've retargeted this at 3.4.1. Zack, does the c-decl rewrite fix this one too?
Regarted at 3.4.1.
One of the primary platforms (sparc-sun-solaris2.8) use stabs by default.
Subject: Re: [3.4/3.5 regression] incorrect stabs for nested local variables This one, unfortunately, is not fixed by the c-decl rewrite; I mean to look at it as soon as I get the rewrite laid down, but my time is very limited for the next two weeks. zw
Subject: Re: [3.4/3.5 regression] incorrect stabs for nested local variables ebotcazou at gcc dot gnu dot org wrote: >------- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-03-21 18:07 ------- >One of the primary platforms (sparc-sun-solaris2.8) use stabs by default. > > How unfortunate. As a SPARC user, do you think this is a showstopper problem?
Probably no, since GCC can generate DWARF-2 debug info on Solaris 7 and later, that both DBX and GDB can grok (DWARF-2 is not available on Solaris 2.6 and earlier). But it would be nice to fix it on the 3.4 branch at some point.
Subject: Re: [3.4/3.5 regression] incorrect stabs for nested local variables Should DWARF-2 be the default for Solaris 7 and later, then? I'm in favor of anything that decreases use of stabs!
I guess so, since DWARF-2 is already the default for 64-bit code. Mark, do you think we can switch the default debug format for 32-bit code too?
Subject: Re: [3.4/3.5 regression] incorrect stabs for nested local variables ebotcazou at gcc dot gnu dot org wrote: >------- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-03-29 16:52 ------- >I guess so, since DWARF-2 is already the default for 64-bit code. > >Mark, do you think we can switch the default debug format for 32-bit code too? > > Yes, I do, actually. It would be good to do a little testing there to make sure that GDB basically works, but it's hard for me to see how DWARF-2, which we use on so many systems, including other SPARC configurations, could be worse than STABS.
Eric -- didn't we end up switching to DWARF for Solaris? If so, would you please close this as WONTFIX? Postponed until GCC 3.4.2 in the meanwhile.
> Eric -- didn't we end up switching to DWARF for Solaris? Yes, we did. This uncovered a couple of issues, one in each of the 2 supported assemblers, but nothing that would justify the backwards move I'd say. > If so, would you please close this as WONTFIX? Done.
Subject: Re: [3.4/3.5 regression] incorrect stabs for nested local variables Doesn't this bug still affect HEAD stabs generation? Surely SPARC/Solaris was not the only platform left which used stabs.
Yes, Mac OS X (darwin) is effect also (even though dwarf-2 support was just added, it is still not the default).
Subject: Bug 13956 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: zack@gcc.gnu.org 2004-08-04 07:32:20 Modified files: gcc : ChangeLog dbxout.c Log message: PR 13956 * dbxout.c (dbx_output_lbrac, dbx_output_rbrac): New functions, broken out of dbxout_block. (dbxout_block): The block at depth 0 should get LBRAC/RBRAC stabs too, if it contains symbols. Use the begin_label and the Lscope label (emitted by dbxout_function_end) for the range of this block. (dbxout_function_decl): Always call dbxout_function_end. (dbxout_function_end): Return after emitting the "Lscope" symbol under the same conditions that this function formerly wasn't called. Add explanatory comments. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.573&r2=2.2326.2.574 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dbxout.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.172.2.1&r2=1.172.2.2
there.
The cvs commit message for mainline erroneously got attached to PR 13596. It is fixed on mainline, though. W.
gcc HEAD works great for me. I tested it on three examples that I had and it worked on all of them. Also I ran the gdb test suite on native i686-pc-linux-gnu with this test matrix: gdb 6.1.1, gdb HEAD gdb test suite HEAD, with local modifications gcc 3.4.1, gcc HEAD 20040731, gcc HEAD 20040804 debug formats dwarf2, stabs+ The bugs got fixed (gdb.base/scope.exp in particular) and no new regressions appeared. Cheers for Zack!