Bug 12500 - stabs debug info -- void no longer a predefined / builtin type
Summary: stabs debug info -- void no longer a predefined / builtin type
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 3.3.1
: P2 normal
Target Milestone: 3.3.3
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-10-03 15:48 UTC by David Taylor
Modified: 2003-10-22 17:14 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-10-11 02:34:35


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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 dtaylor@emc.com 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:	jason@gcc.gnu.org	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:	jason@gcc.gnu.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=1.130.2.1&r2=1.130.2.2

Comment 7 Andrew Pinski 2003-10-22 17:14:13 UTC
Fixed for 3.3.3 and 3.4.