|Summary:||stabs debug info -- void no longer a predefined / builtin type|
|Product:||gcc||Reporter:||David Taylor <dctaylor87>|
|Component:||debug||Assignee:||Not yet assigned to anyone <unassigned>|
|Build:||Known to work:|
|Known to fail:||Last reconfirmed:||2003-10-11 02:34:35|
Description David Taylor 2003-10-03 15:48:16 UTC
[Observed in i686-pc-linux-gnu native and i686-pc-linux-gnu x powerpc-elf-eabi; but problem is really configuration independent.] Pick your favorite .c file, compile it with -gstabs -S, and examine the output. At the top of the file you will find the stabs entries for the predefined / builtin data types -- int, char, short, long, et cetera. In 2.95.3, the list included 'void'; in 3.3.1, void is absent. This causes subsequent errors in the debug information for functions and variables that reference void. The fix is a one liner -- file gcc/dbxout.c, function dbxout_typedefs, change the line: && COMPLETE_TYPE_P (type) to: && COMPLETE_OR_VOID_TYPE_P (type) With this patch, it bootstraps just fine. I'm running the testsuite now for i686-pc-linux-gnu native; so far no regressions.
Comment 1 Andrew Pinski 2003-10-05 06:20:35 UTC
This patch added COMPLETE_TYPE_P and COMPLETE_OR_VOID_TYPE_P is <http:// gcc.gnu.org/ml/gcc-patches/2000-03/msg00713.html> but there was no check to behavior with this patch but there was president for a change like this: <http:// gcc.gnu.org/ml/gcc-patches/2001-09/msg00102.html>.
Comment 2 Daniel Jacobowitz 2003-10-10 14:23:09 UTC
Hi David, Could you provide a testcase where the missing type causes a problem?
Comment 3 firstname.lastname@example.org 2003-10-10 16:59:03 UTC
Subject: stabs debug info -- void no longer a predefined / builtin type ------- Additional Comments From drow at gcc dot gnu dot org 2003-10-10 14:23 - ------ Hi David, Could you provide a testcase where the missing type causes a problem? I don't have one handy; but, with some hints / help, I'd be glad to. How does one write a gcc (not gdb!) testcase to test the debug information? Are there existing examples? BTW, I consider my one line fix to be low risk because: . it does not affect code generation for ANY targets, regardless of the command line options . it only affects stabs debug information . the function modified is only called once; and it only produces one additional line of stabs output -- a line of output that was present in 2.95.3. . the compiler bootstraps just fine . void was the only deletion; and it appears to have been done accidentally as a side effect of another change (so, I believe that putting it back is "the right fix"). . we are using it in house and it works NOTE: The problem was initially observed internally using a locally written stabs parser. I believe that there were structs containing pointers to void and they got mis-represented as either instances of non-existent types or self referential types or some such. The types printed in 2.95.3 permit you to generate correct debug information for things like: void *foo; Whereas I believe that the types printed in 3.3.1 -- wihich do not contain a void of any flavor -- do not permit such.
Comment 4 Daniel Jacobowitz 2003-10-10 17:13:45 UTC
Subject: Re: stabs debug info -- void no longer a predefined / builtin type On Fri, Oct 10, 2003 at 04:59:06PM -0000, dtaylor at emc dot com wrote: > I don't have one handy; but, with some hints / help, I'd be glad to. > > How does one write a gcc (not gdb!) testcase to test the debug information? > Are there existing examples? I don't need an automated testcase. I need something that will explain the problem. I don't see the problem here so I need to understand why you do. The answer involves scan-assembly or something similar to that. > The types printed in 2.95.3 permit you to generate correct debug > information for things like: > > void *foo; > > Whereas I believe that the types printed in 3.3.1 -- wihich do not > contain a void of any flavor -- do not permit such. That's not correct since it worked in GDB. Which is where we usually test such things. However, that was enough information to generate a testcase; I believe your patch is right. Please send it to gcc-patches.
Comment 5 CVS Commits 2003-10-22 14:28:12 UTC
Subject: Bug 12500 CVSROOT: /cvs/gcc Module name: gcc Changes by: email@example.com 2003-10-22 14:28:09 Modified files: gcc : ChangeLog dbxout.c Log message: PR debug/12500 * dbxout.c (dbxout_typedefs): Use COMPLETE_OR_VOID_TYPE_P. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.1516&r2=2.1517 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dbxout.c.diff?cvsroot=gcc&r1=1.163&r2=1.164
Comment 6 CVS Commits 2003-10-22 14:29:11 UTC
Subject: Bug 12500 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: firstname.lastname@example.org 2003-10-22 14:29:04 Modified files: gcc : ChangeLog dbxout.c Log message: PR debug/12500 * dbxout.c (dbxout_typedefs): Use COMPLETE_OR_VOID_TYPE_P. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.786&r2=1.16114.2.787 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dbxout.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=184.108.40.206&r2=220.127.116.11
Comment 7 Andrew Pinski 2003-10-22 17:14:13 UTC
Fixed for 3.3.3 and 3.4.