I added a recipe called 'symbols' to my makefile to create a two part executable. When I attempt to use objcopy to embed the debug information file in the executable: $ make symbols objcopy --only-keep-debug cryptest.exe cryptest.exe.debug strip --strip-debug --strip-unneeded cryptest.exe objcopy --add-gnu-debuglink=/usr/lib/debug/cryptest.exe.debug cryptest.exe objcopy:stOV5Ij1: cannot fill debug link section `/usr/lib/debug/cryptest.exe.debug': No such file or directory make: [symbols] Error 1 And: objcopy --only-keep-debug libcryptopp.so libcryptopp.so.debug strip --strip-debug --strip-unneeded libcryptopp.so objcopy --add-gnu-debuglink=/usr/lib/debug/libcryptopp.so.debug libcryptopp.so objcopy:stLaJYWV: cannot fill debug link section `/usr/lib/debug/libcryptopp.so.debug': No such file or directory make: [symbols] Error 1 It seems objcopy requires the referenced path to exist in advance. The man pages don't discuss the behavior, so I'm not sure if its expected or not. And I was not able to locate an option to ignore non-existent paths. This causes a problem in practice because I'm still the building software. And when it comes time to install the software, `make install` MUST NOT build anything (according to Stallman's GNU Make). Collectively, `make && sudo make install` is effectively not working as expected. I also build GDB and LLDB on occasion, so I try not depend on the GDB and LLDB's built-in debug information directories being a correct. In fact, I'm not sure GDB is configured correctly when using the distro's package. `show debug-file-directory` is missing paths that the distro uses, like `/usr/lib/debug/lib/x86_64-linux-gnu`. ***** I think two or three things would be helpful. First, discuss the expected behavior in the man pages under the --add-gnu-debuglink section. Second, change the behavior of --add-gnu-debuglink to allow a reference to a non-existent debug information file in anticipation of an install. This may be undesirable for those who expect a failure to stop a script. Third, add another option that provides an override to --add-gnu-debuglink's existing behavior. That is, allow it to reference a non-existent debug information file in anticipation of an install. This may be the best solution moving forward even though the option will not be available to downlevel versions of binutils. Are there any other options? ***** $ apt-cache showpkg binutils Package: binutils Versions: 2.24-5ubuntu3.1 (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_trusty-updates_main_binary-amd64_Packages) (/var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_trusty-security_main_binary-amd64_Packages) (/var/lib/dpkg/status) Description Language: File: /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_trusty_main_binary-amd64_Packages MD5: fde49b4cfeaad346a6e094f973da28d7 Description Language: en File: /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_trusty_main_i18n_Translation-en MD5: fde49b4cfeaad346a6e094f973da28d7
I probably should have added this to the original report. Its from https://sourceware.org/binutils/docs/binutils/objcopy.html, which is the same as objcopy(1): --add-gnu-debuglink=path-to-file Creates a .gnu_debuglink section which contains a reference to path-to-file and adds it to the output file. As far as I know, that's all the man pages have to say about it.
Hi Jeffrey, > It seems objcopy requires the referenced path to exist in advance. The man > pages don't discuss the behavior, so I'm not sure if its expected or not. And > I was not able to locate an option to ignore non-existent paths. It is the expected behaviour, but you are correct, this should be mentioned in the man page. The reason for this requirement is that the .gnu_debuglink section created by the --add-gnu-debuglink option contains both the filename of the separate debug info file and a CRC checksum of the contents of the separate debug info file. This is so that a debugger can verify that the debug info it reads in really does match up with the file that it is supposed to be debugging. Hence it is necessary to have the debug info file present, readable and up-to-date when the debug link is created. > This causes a problem in practice because I'm still the building software. You should be able to solve this problem by removing the fully qualified path from the build. Ie: objcopy --only-keep-debug cryptest.exe cryptest.exe.debug strip --strip-debug --strip-unneeded cryptest.exe objcopy --add-gnu-debuglink=cryptest.exe.debug cryptest.exe This ought to work (since the cryptest.exe.debug file exists in the local directory). Locating the debug info file at gdb runtime should work provided that the file has been copied to a location that gdb expects. This does vary depending upon the release that you are using, but it usually involves well known directories such as /usr/lib/debug. In the meantime I will update the objcopy manual page. Cheers Nick
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4fd77a3d12291cd9351e1f776a5ade11f99a28ac commit 4fd77a3d12291cd9351e1f776a5ade11f99a28ac Author: Nick Clifton <nickc@redhat.com> Date: Thu Mar 5 16:45:15 2015 +0000 Extend description of --add-gnu-debuglink option to explain why the file must exist. PR binutils/18064 * doc/binutils.texi (objcopy): Extend description of --add-gnu-debuglink option to explain that the separate debug info file must exist. Add a description of what to do if the debug info file is built in one place but then installed into a separate location.
(In reply to cvs-commit@gcc.gnu.org from comment #3) > The master branch has been updated by Nick Clifton <nickc@sourceware.org>: > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=4fd77a3d12291cd9351e1f776a5ade11f99a28ac > > commit 4fd77a3d12291cd9351e1f776a5ade11f99a28ac > Author: Nick Clifton <nickc@redhat.com> > Date: Thu Mar 5 16:45:15 2015 +0000 > > Extend description of --add-gnu-debuglink option to explain why the file > must exist. > > PR binutils/18064 > * doc/binutils.texi (objcopy): Extend description of > --add-gnu-debuglink option to explain that the separate debug info > file must exist. Add a description of what to do if the debug > info file is built in one place but then installed into a separate > location. Perfect, thanks Nick. The first cold beer is on me.
.