Debugging Symbols Lost When Linking?

Question

I'm trying to compile a program with debugging symbols so that valgrind will give me line numbers. I have found that if I compile a simple test program in one go (with -g) then it contains the symbols. However, if I compile in two passes (i.e. compile then link) then it does not contain the debugging symbols.

Here's the compile command for the single pass case:

g++ -g file.c -o file

And for two passes

g++ -g -c file.c -o file.o
g++ -g file.o -o file

The actual program looks like this and contains a simple Invalid Write

int main(){
    int* x = new int[10];
    x[10]=1;

}

If I compile with one pass then valgrind gives the following (note the line number at the end)

==24114== 40 bytes in 1 blocks are definitely lost in loss record 2 of 9
==24114==    at 0xB823: malloc (vg_replace_malloc.c:266)
==24114==    by 0x5768D: operator new(unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib)
==24114==    by 0x576DA: operator new[](unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib)
==24114==    by 0x100000F09: main (file.c:3)

whereas if I compile in two passes I get this (with no line number):

==24135== 40 bytes in 1 blocks are definitely lost in loss record 2 of 9
==24135==    at 0xB823: malloc (vg_replace_malloc.c:266)
==24135==    by 0x5768D: operator new(unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib)
==24135==    by 0x576DA: operator new[](unsigned long) (in /usr/lib/libstdc++.6.0.9.dylib)
==24135==    by 0x100000F09: main (in ./file)

Any insight on this would be much appreciated. I am using gcc version 4.2.1 on OS X 10.7.3

Answer 1

Final remark - it was indeed an OS X specific 'feature' to do with the way OS X links debug information. Valgrind helps the user circumvent the problem with the command --dsymutil=yes.

You can read more about it here: http://valgrind.org/docs/manual/manual-core.html#manual-core.erropts

Credit to Dave Goodell who sent me the solution on valgrind users forum.

Answer 2

Just for marking this question as "answered" (so it's not needlessly opened and read by others).

=> Answer is found as the comment from "user1288111" to the initial question.