[CMake] Fwd: Save stripped debugging information

[Rolf Eike Beer]

> On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
>> When I was investigating similar problem, I found alternative approach
>> at
>> http://code.google.com/p/dynamorio/source/browse/trunk/CMakeLists.txt.
>>
>> The thing is to change linker rules, to something like this:
>>     set(CMAKE_C_CREATE_SHARED_LIBRARY
>>         # standard rule
>>         "<CMAKE_C_COMPILER> <CMAKE_SHARED_LIBRARY_C_FLAGS>
>> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS>
>> <CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS>
>> <CMAKE_SHARED_LIBRARY_SONAME_C_FLAG><TARGET_SONAME> -o <TARGET>
>> <OBJECTS>
>> <LINK_LIBRARIES>"
>>         # now create a .debug copy
>>         "${CMAKE_OBJCOPY} --only-keep-debug <TARGET> <TARGET>.debug"
>>         # link original to point at .debug copy
>>         # directory components are removed, so "../lib/" is fine
>>         "${CMAKE_OBJCOPY} --add-gnu-debuglink=<TARGET>.debug <TARGET>"
>>         # Strip all information from target binary.
>>         "${CMAKE_STRIP} --strip-debug --discard-all --preserve-dates
>> <TARGET>"
>>     )
>>
>> I don't exactly remember benefits from this approach but it kind of
>> works.
>
> The benefits are that one needs to define these rule variables once as
> they're inherited by the subdirectories. The downside is that the rule
> variables are used by Makefile generators only, whereas the target-
> associated custom commands are a more generic approach.
>
>> And I agree that functionality like installing debug symbols in
>> install()
>> rules out of box would be quite handy.
>
> INSTALL() is essentially about copying files and directories, so it
> doesn't depend on the toolchain; in particular, you can use INSTALL()
> for projects which are configured with PROJECT(... NONE), i.e. without
> any toolchain. By contrast, extracting debug symbols does highly depend
> on the toolchain, e.g. the objcopy(1) utility isn't mentioned in POSIX,
> and even with the GNU tools, you have multiple possibilities to connect
> the stripped binary with the unstripped one, note --add-gnu-debuglink
> vs. build IDs. Windows and MacOSX will further enrich this entire zoo
> of utilities and command line switches, not to mention toolchains for
> specific platforms. So, opening and parameterizing INSTALL() - w.r.t.
> its interface and its implementation - in order to provide reasonable
> support for the extraction of debug symbols during installation is a
> major undertaking, IMO, besides the conceptional issue of toolchain-
> dependence.

The idea was not to generate those during install, but to be able to let
them being installed. For e.g. MSVC you don't have anything to do, the
linker will already generate the PDB file already. So all you would have
to do would be to copy the generated debug file to the proper place. This
whish  comes from the fact that for multi-configuration generators you
don't know which configuration is active so you don't know where to search
the PDB file. And INSTALL() and ADD_CUSTOM_TARGET()/_COMMAND() don't
understand generator expressions.

So my idea would be to generate the debug file during or after the link
step and save the position to this file somewhere internally, so
INSTALL(... DEBUG_SYMBOLS) would know which to take. Or to do just nothing
if we do not support external debug symbols on this platform.

Eike