Created attachment 14298 [details] binary test case in pe format Running objdump -WL on a binary in pe format generated with i686-w64-mingw32-ld version 2.39 returns incorrect file paths. run the following commands to reproduce: mkdir -p ~/test-binutils && cd ~/test-binutils cat << EOF > test.c #include <stdio.h> int main() { printf("hello world"); return 0; } EOF mkdir output mkdir build && cd build 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: where it should be /home/<user>/src/test-binutils/test.c:
(In reply to Ralf Habacker from comment #0) > > /home/<user>/src/test-binutils/build/test.c: > > where it should be > > /home/<user>/src/test-binutils/test.c: that needs minor path correction: The output is /home/<user>/test-binutils/build/test.c: where it should be /home/<user>/test-binutils/test.c:
objdump -Wi ../output/test.exe dumps <0><251a>: Abbrev Number: 9 (DW_TAG_compile_unit) <251b> DW_AT_producer : GNU C17 12.1.0 -mtune=generic -march=pentiumpro -g <254e> DW_AT_language : 29 (C11) <254f> DW_AT_name : (indirect line string, offset: 0x20c): ../test.c <2553> DW_AT_comp_dir : (indirect line string, offset: 0x1e9): /home/ralf/src/test-binutils/build and objdump -Wl ../output/test.exe dumps The Directory Table (offset 0x4ab, lines 3, columns 1): Entry Name 0 (indirect line string, offset: 0x216): /home/<user>/test-binutils/build 1 (indirect line string, offset: 0x239): .. 2 (indirect line string, offset: 0x23c): /usr/i686-w64-mingw32/sys-root/mingw/include The File Name Table (offset 0x4bd, lines 4, columns 2): Entry Dir Name 0 1 (indirect line string, offset: 0x269): test.c 1 2 (indirect line string, offset: 0x270): stdio.h 2 1 (indirect line string, offset: 0x278): test.c 3 2 (indirect line string, offset: 0x27f): vadefs.h which shows that -Wl drops '../' from the file name generating an invalid path. If the filename table really contains only the filename, the path with index 0 in the directory table should be '/home/<user>/test-binutils/build/...' -> '/home/<user>/test-binutils'.
The issue seems to be caused by the assembler as running: $ cd ~/test-binutils/build $ i686-w64-mingw32-gcc -C ../test.c -o test.o -g $ objdump -WL test.o | grep "^/.*test.c:$" /home/<user>/test-binutils/build/test.c: shows that the incorrect path is already present in the object file.
(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.
Created attachment 14308 [details] tests: assembler output of mentioned problem generated by i686-w64-mingw32-gcc -S -o test.s ~/src/test-binutils/test.c -g
(In reply to Ralf Habacker from comment #5) The object file generated from the related source file with $ cd ~/src/test-binutils/build $ i686-w64-mingw32-gcc -c -o test.o ~/src/test-binutils/test.c -g shows a filename located in the working directory from which the compiler has bee run $ objdump -WL test.o | grep test.c test.c: /home/<user>/src/test-binutils/build/test.c: test.c 4 0x3c x test.c 4 0x45 x test.c 5 0x4a x test.c 6 0x56 x test.c 7 0x5b x test.c - 0x5d
Created attachment 14318 [details] Proposed Patch Hi Ralf, Stupid DWARF-5, it has been the bane of my existence recently. This is another of the DWARF-5-indexes-file/dir-tables-from-0 bugs. Please try out the uploaded patch and let me know if it works for you. Cheers Nick
(In reply to Nick Clifton from comment #7) Hi Nick, > Please try out the uploaded patch and let me know if it works for you. Thank you for your support. Unfortunally the patch does not seem to fit on the git master branch user@host:~/src/binutils-gdb> git remote -v origin git://sourceware.org/git/binutils-gdb.git (fetch) origin git://sourceware.org/git/binutils-gdb.git (push) user@host:~/src/binutils-gdb> git branch master user@host:~/src/binutils-gdb> git pull --rebase user@host:~/src/binutils-gdb> git apply ~/Downloads/pr29523.txt error: Failed to apply the patch: binutils/dwarf.c:5215 error: binutils/dwarf.c: patch could not be applied Can you rebase it ?
Created attachment 14319 [details] patched version of dwarf.c Hi Ralf, Strange - it works perfectly for me, using the same steps as you did. I have uploaded the patched version of binutils/dwarf.c instead. Maybe you can use it as a drop in replacement ? Cheers Nick
(In reply to Nick Clifton from comment #9) > Strange - it works perfectly for me, using the same steps as you did. (In reply to Ralf Habacker from comment #8) > user@host:~/src/binutils-gdb> git pull --rebase Fetching from the git server seemed to be delayed because a replay yesterday afternoon brought some additional commits to which the patch could be applied. > Please try out the uploaded patch and let me know if it works for you. i686-w64-mingw32-objdump -WL test.o | grep test.c test.c: /home/<user>/src/test-binutils/test.c: ... The -WL command now works as expected, thanks for support.
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2caffd34df293680755ebad35c618ee68686fcf1 commit 2caffd34df293680755ebad35c618ee68686fcf1 Author: Nick Clifton <nickc@redhat.com> Date: Thu Sep 8 09:56:39 2022 +0100 i686-w64-mingw32-objdump -WL returns incorrect file paths PR 29523 * dwarf.c (display_debug_lines_decoded): Correctly handle DWARF-5 directory and filename tables.
Patch applied.