[CMake] Fwd: Save stripped debugging information

Mon Oct 3 03:18:35 EDT 2011

Hi Michael,

On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling <mhertling at online.de>wrote:

> On 10/01/2011 10:07 AM, Yuri Timenkov wrote:
> > that's the problem: you don't know neither file name nor it's location,
> > especially in multi-configuration generators.
>
> You *do* know a debug file's name and location, either because you must
> generate it explicitly (objcopy approach) or via the concerned target's
> $<TARGET_FILE_DIR:...> generator expression in custom targets/commands
> (Visual approach). Otherwise, a debug file with unknown name and/or
> location would be rather useless.
>
I'm sorry that you misunderstood me, but I was concerned about install()
commands.

CMake already does a lot of things to make different platforms and
generators work in same way. As it was noted before, install already knows
about such subtleties between generators and platforms like export
libraries. So why not make it aware of separate debug information?

Adding objcopy/whatever to separate debug information to out-of-box CMake is
just one more step to unifying different platforms and generators.
Basically, in Makefile generator there are a lot of things that VS provides
from GUI (fast build, compile only file).

Of course it should be controlled through policy, property or variable to
keep backward compatibility.

> W.r.t. a debug file's installation, one must currently take generator-
> specific measures: Either generate the file at all (objcopy approach)
> or copy it to a configuration-independent location (Visual approach).
> This might be considered as annoying, but it can be easily achieved
> with CMake's present means, so I'm not fully aware of the actual
> problem we're discussing ATM.
>
> > It's also bad idea to mix build and install steps. [...]
>
> Absolutely.
>
> > [...] Install command doesn't
> > understand generators expressions.
>
> Regarding files that
>
> - should be installed,
> - are not target binaries,
> - are put in configuration-specific locations,
>
> it would be handy to have generator expressions available in
> the INSTALL() command; perhaps; that's worth a feature request.
>
> > If it were possible to emulate vs behavior for gcc things would be much
> > easier in some cases. [...]
>
> In which cases?
>
install debug into separate location for further usage, like generating
"runtime" and "devel" packages. The third one is "debug".

>
> > [...] However extracting debug info from binaries is
> > performed by packager (at least rpmbuild does this)
>
> Sometimes - or quite often, as the case may be - packages are installed
> without any packager's ado, and with a simple tar archive, e.g., you'll
> be out of luck, too, so one shouldn't rely on a packager's capabilities
> when it comes to the extraction of debug information or the like, IMO.
>
Yes, in proprietary software there are no packagers, so it is essential to
have an option to keep debug information after the build. I think that's
exactly why this question arose.

>
> Regards,
>
> Michael
>
> > On Oct 1, 2011 8:09 AM, "Michael Hertling" <mhertling at online.de> wrote:
> >> On 09/30/2011 08:39 AM, Rolf Eike Beer wrote:
> >>>> 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.
> >>
> >> INSTALL() doesn't, but ADD_CUSTOM_TARGET/COMMAND() are right the two
> >> commands which *do* understand generator expressions. As long as you
> >> know the location of the debug files relative to the location of the
> >> concerned target's binary, the $<TARGET_FILE_DIR:target> expressions
> >> should do the trick. So, the worst case you might suffer is that you
> >> must use a custom target/command to copy or move the debug files to
> >> a suitable location in order to apply INSTALL(FILES ...) on them in
> >> the end. IMO, that's bearable; does it not work for you? However,
> >> adding generator expressions to the INSTALL() command might be
> >> worth a thought.
> >>
> >>> 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.
> >>
> >> What do you mean with "save the position to this file somewhere
> >> internally"? Saving by a user's action, i.e. declaring a file as a
> >> debug file? If you know the file's name and location, you can simply
> >> apply INSTALL(FILES ...) on it, perhaps with an intermediate step as
> >> suggested above. Saving by action of CMake, i.e. without specifying
> >> the debug file's name and/or location? For this to work, you would
> >> need to teach CMake to recognize a debug file by itself, and that's
> >> probably a comparably complicated undertaking as teaching CMake how
> >> to generate debug files. E.g., with a typical *nix toolchain, CMake
> >> has no chance to know in advance *if* a debug file is generated,
> >> *where* it is written to and *what* is its name.
> >>
> >> Regards,
> >>
> >> Michael
> --
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111003/d2a7cd58/attachment-0001.htm>