Bug 7190 - commandline macros (-D) have non-zero lineno when using -g3
Summary: commandline macros (-D) have non-zero lineno when using -g3
Status: CLOSED FIXED
Alias: None
Product: ccache
Classification: Unclassified
Component: ccache (show other bugs)
Version: 2.4
Hardware: Other Linux
: P3 normal
Target Milestone: 3.0
Assignee: Joel Rosdahl
QA Contact: Joel Rosdahl
URL: https://bugzilla.redhat.com/show_bug....
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-01 16:53 UTC by Ville Skyttä
Modified: 2010-07-09 04:18 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ville Skyttä 2010-03-01 16:53:29 UTC
I maintain the ccache package in Fedora, and I'm forwarding a bug report from https://bugzilla.redhat.com/show_bug.cgi?id=488863 here, this seems reproducible (at least the second part, I suspect the CORRECT/INCORRECT in the first one are swapped, i.e. the first one is actually incorrect, the latter correct) with 3.0pre0:

----

 Jan Kratochvil      2009-03-05 19:22:57 EST

Description of problem:
http://dwarf.freestandards.org/Dwarf3.pdf section 6.3.3 says the command-line
macros should have line number of their definition zero.
This is true for /usr/bin/gcc but in some cases `cache gcc' sets them non-zero.

Version-Release number of selected component (if applicable):
ccache-2.4-13.fc9.x86_64
gcc-4.3.2-7.x86_64

How reproducible:
Always.

CORRECT:
$ : >empty.c; ccache gcc -c -o empty.o empty.c -g3; readelf -wm empty.o \
  | grep __GNUC__
 DW_MACINFO_define - lineno : 3 macro : __GNUC__ 4

INCORRECT:
$ : >empty.c; /usr/bin/gcc -c -o empty.o empty.c -g3; readelf -wm empty.o \
  | grep __GNUC__
 DW_MACINFO_define - lineno : 0 macro : __GNUC__ 4

$ cat somefile.c
int
main (void)
{
  return 0;
}

CORRECT:
$ /usr/bin/gcc -c -o somefile.o somefile.c -Wall -g3;
$ /usr/bin/gcc -o somefile somefile.o -Wall
$ ~jkratoch/redhat/gdb-cvs-clean/gdb/gdb -q ./somefile
(gdb) start
Temporary breakpoint 1 at 0x400480: file somefile.c, line 4.
Starting program: /tmp/somefile 

Temporary breakpoint 1, main () at somefile.c:4
4         return 0;
(gdb) info macro __GNUC__
Defined at /tmp/somefile.c:0
#define __GNUC__ 4

INCORRECT:
$ ccache gcc -c -o somefile.o somefile.c -Wall -g3
$ gcc -o somefile somefile.o -Wall
$ ~jkratoch/redhat/gdb-cvs-clean/gdb/gdb -q ./somefile
(gdb) start
Temporary breakpoint 1 at 0x400480: file somefile.c, line 4.
Starting program: /tmp/somefile 

Temporary breakpoint 1, main () at somefile.c:4
4         return 0;
(gdb) info macro __GNUC__
Defined at /tmp/somefile.c:3
#define __GNUC__ 4
(gdb) l
1       int
2       main (void)
3       {
4         return 0;
5       }

Single-step compilation (without the `somefile.o' intermediate) does not
reproduce the problem.
Comment 1 Jan Kratochvil 2010-03-01 17:27:46 UTC
Ville correctly pointed out the empty.c example has really swapped the CORRECT<->INCORRECT labels.
Comment 2 Joel Rosdahl 2010-03-04 14:49:35 UTC
This is a consequence of how ccache normally works: It first runs the preprocessor on the source code, saves the output and (on a cache miss) passes the preprocessed source to the real compiler. And apparently, the correct line number information is not preserved when doing this manouver. There is a work-around: Set the CCACHE_CPP2 option.

I have committed a fix in 574ab5a9af08b0639d38b623b2fb7d882272db50.