This is the mail archive of the
mailing list for the GCC project.
[Bug debug/20253] New: [3.4/4.0 regression]: Macro debug info broken due to lexer change
- From: "dberlin at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 28 Feb 2005 19:59:42 -0000
- Subject: [Bug debug/20253] New: [3.4/4.0 regression]: Macro debug info broken due to lexer change
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
the lexer is no longer calling debug_hooks.start_source_file/end_source_file for
the "base compilation file" (IE the one passed on the command line or giving us
something about stdin, if that is the case).
This breaks macro debug info in dwarf2 because the standard specifies we must
have a start/end file pair for the base file.
This problem did not occur in 3.3.4.
Compile the following test case with 3.3.4 and -g3 -gdwarf-2 -fverbose-asm -dA
-save-temps, and look at the .s file:
#define ADD(x) (M + x)
#define N 28
#define M 42
printf ("We're so creative: %d.\n", ADD(N));
For 3.3.4 you will see
.byte 0x3 # Start new file
.uleb128 0x0 # Included from line number 0
.file 1 "sample.c"
.uleb128 0x1 # Filename we just started
.byte 0x4 # End file
.byte 0x0 # End compilation unit
For 3.4/4.0 you will not see these, we just immediately start outputting the macros.
The reason is that debug_hooks.start_source_file/end_source_file is never called
for "sample.c", as it was before.
If someone could reghunt this i'd appreciate it (You should be able to simply
grep the resulting .s file for "End compilation unit" and consider it broken
when it stops appearing).
Summary: [3.4/4.0 regression]: Macro debug info broken due to
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dberlin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org