Follow the steps on either: http://xinutec.org/~pippijn/files/txt/46e78059d1e42f9381587ea2ab502f2b.txt https://gist.github.com/56744b9f0a5b0d69b83e on FreeBSD. Dwarf debug information is wrong, but this only happens on FreeBSD and only if the compiling (-S) and assembling (-c) step are split. It happens for PIC and non-PIC code. It happens for i386 and x86_64. This bug is blocking, because I rely on this separate assembling step due to an assembly code analysis and pattern replacement stage in my build. It is especially blocking, because I can't fix a blocking bug in my own software.
The issue is here: g++ -g -c test.s -o test.o Don't use -g with assembly code that already has debugging info in it. Also I think this was just fixed on the trunk of binutils lately where it checks to make sure that if there is debugging info, don't create new debugging info based on the assembly file.
It works if -g is omitted on the assembling step. Still, the debug information from the asm should not conflict with the original debug information, should it?
(In reply to comment #2) > It works if -g is omitted on the assembling step. Still, the debug information > from the asm should not conflict with the original debug information, should > it? And at that point, this is not a GCC bug but rather a binutils one or a gdb one. binutils contains the assembler. So I am going to close this as invalid. GCC is doing the correct thing of passing -g down the assembler since you asked for it. The assembler might be doing the incorrect thing but that is not GCC's fault. Report it to the binutils team (as I mentioned they just fixed it recently, http://sourceware.org/ml/binutils/2008-08/msg00036.html).
see http://sourceware.org/bugzilla/show_bug.cgi?id=6656 also.