[Bug binutils/18064] New: objcopy, add-gnu-debuglink and "cannot fill debug link section"

[noloader at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18064

            Bug ID: 18064
           Summary: objcopy, add-gnu-debuglink and "cannot fill debug link
                    section"
           Product: binutils
           Version: 2.24
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: noloader at gmail dot com

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.