https://sourceware.org/bugzilla/show_bug.cgi?id=29523
Nick Clifton <nickc at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nickc at redhat dot com --- Comment #4 from Nick Clifton <nickc at redhat dot com> --- (In reply to Ralf Habacker from comment #2) Hi Ralf, > objdump -Wi ../output/test.exe dumps FYI - the paths in the attributes used by the .debug_info section are totally separate from the paths used by the .debug_line section. > i686-w64-mingw32-gcc ../test.c -o ../output/test.exe -g > objdump -WL ../output/test.exe | grep test.c: > The output is > /home/<user>/src/test-binutils/build/test.c: Are you sure that this is the output ? That gcc command uses relative paths not absolute ones. When I tried the same on my local machine I saw: % gcc -g ../test.c -o ../output/test.exe % objdump -WL ../output/test.exe | grep test.c CU: ./../test.c: This was on a Linux box, so maybe there is a difference when building with a mingw32 compiler. As a test I tried compiling with an absolute path to the source file: % gcc -g `pwd`/../test.c -o ../output/test.exe % objdump -WL ../output/test.exe | grep test.c CU: .//home/nickc/work/builds/binutils/current/x86_64-pc-cygwin/tests/delme/../test.c: The .// at the start is a little bit weird, but I think that it should be correct. Assuming that you still think that there is a problem, would you mind uploading the assembler output from gcc when it compiles test.c. That should show allow us to determine if the compiler is providing the wrong information to the assembler, or if the assembler is mis-constructing the .debug_line section. -- You are receiving this mail because: You are on the CC list for the bug.