[CMake] Fwd: Save stripped debugging information

[Michael Hertling]

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.

Regards,

Michael

> Regards,
> Yuri
> 
> On Sat, Sep 24, 2011 at 4:02 AM, Michael Hertling <mhertling at online.de>wrote:
> 
>> On 09/22/2011 01:24 PM, Rolf Eike Beer wrote:
>>>> Il 22/09/2011 10.13, Rolf Eike Beer ha scritto:
>>>>>> Yeah, that's exactly what I had in mind. Any chance that we will see
>>>>>> this in a future release?
>>>>> This is usually "find someone who does it and writes tests for it".
>>>>> Which
>>>>> then boils down to find someone who has enough knowledge and spare time
>>>>> to
>>>>> do or someone that needs it and is willing to pay Kitware for doing it.
>>>
>>>> Why don't you invoke ${CMAKE_OBJCOPY} as a post build command?
>>>
>>> That would be a way to _get_ these debug symbol files, but not a clean
>> way
>>> to _install_ them. And the other reason is that this variable doesn't
>> show
>>> up in any CMake documentation.
>>>
>>> Eike
>>
>> In order to take up Andrea's suggestion for Lukas' concern:
>>
>> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
>> PROJECT(DEBUGINFO C)
>> SET(CMAKE_VERBOSE_MAKEFILE ON)
>> FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
>> ADD_EXECUTABLE(main main.c)
>> FIND_PROGRAM(OBJCOPY objcopy)
>> ADD_CUSTOM_COMMAND(TARGET main POST_BUILD
>>    COMMAND ${OBJCOPY} --only-keep-debug
>>        $<TARGET_FILE:main> ${CMAKE_BINARY_DIR}/main.dbg
>>    COMMAND ${OBJCOPY} --strip-debug
>>        $<TARGET_FILE:main>
>>    COMMAND ${OBJCOPY} --add-gnu-debuglink=main.dbg
>>        $<TARGET_FILE:main>
>> )
>> INSTALL(TARGETS main RUNTIME DESTINATION bin)
>> INSTALL(FILES ${CMAKE_BINARY_DIR}/main.dbg DESTINATION bin)
>>
>> This exemplary project simply follows objcopy's manpage
>> w.r.t. the --only-keep-debug switch and works on *nix.
>> Does it not work for you, or is it not clean enough?
>>
>> Regards,
>>
>> Michael