bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/18064] objcopy, add-gnu-debuglink and "cannot fill debug l


From: nickc at redhat dot com
Subject: [Bug binutils/18064] objcopy, add-gnu-debuglink and "cannot fill debug link section"
Date: Thu, 05 Mar 2015 16:21:23 +0000

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

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |nickc at redhat dot com

--- Comment #2 from Nick Clifton <nickc at redhat dot com> ---
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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]