[CMake] Fwd: Save stripped debugging information

[Rolf Eike Beer]

Am Donnerstag, 13. Oktober 2011, 20:09:04 schrieb Michael Hertling:
> On 10/12/2011 03:40 PM, Rolf Eike Beer wrote:
> >> On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
> >>> 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?
> >> 
> >> Because, IMO, the platform/generator independent extraction and/or
> >> recognition of debug info files is significantly more difficult to
> >> specify than the handling of DLLs along with their import libraries
> >> in VS, e.g. AFAICS, the latter works well since the import libraries
> >> are generated next to their DLLs sharing the same base name, and both
> >> are covered by INSTALL()'s RUNTIME/ARCHIVE DESTINATION clauses which
> >> also have a defined meaning on *nix. For VS alone, the installation
> >> of debug info files would in fact be as easy as the installation of
> >> an import library, but how would you specify and parameterize this
> >> task on *nix? With the GNU toolchain, CMake can't know in advance if
> >> and how debug info files are generated, where they're written to etc.
> > 
> > I think you got something reverse here.
> > 
> > To actually get the debug information in a separate file with binutils
> > you need to run objcopy. [...]
> 
> No, you can use the full symbol-equipped executable as debug info file:
> 
> <cite src="man objcopy">
> 
> Also the --only-keep-debug step is optional. You could instead do this:
> 
>    1. Link the executable as normal.
>    2. Copy foo to foo.full
>    3. Run objcopy --strip-debug foo
>    4. Run objcopy --add-gnu-debuglink=foo.full foo
> 
> i.e., the file pointed to by the --add-gnu-debuglink can be the full
> executable. It does not have to be a file created by the
> --only-keep-debug switch.
> 
> </cite>
> 
> As you can see, the debug info file is *not* generated by objcopy; it's
> just a copy of the original non-stripped binary. The --only-keep-debug
> switch is virtually the complement of --strip-debug; essentially, it
> removes non-debug-related sections - convenient but not necessary.

Yes it's a copy. So someone has to do this. And to know the location. And this 
is CMake. So CMake will do the copy, call the objdump and do other fancy 
things. But it is completely driven by CMake, so CMake knows which files are 
involved. It's not that at any point CMake is calling a program that would 
magically create files at places that CMake doesn't know of before, all output 
filenames will be specified by CMake.

The only thing that may "magically" happen is the generation of the build id. 
But that will not create a file on it's own, and CMake can easily read the 
build id out of the generated executable. The file named after the build id is 
later created by cp, objcopy, or CMake. And once again CMake would know about 
the name.

> > -optionally, and only on installation, check if the file has a build-id
> > (using readelf, objdump or whatever) [...]
> 
> objdump -s -j .note.gnu.build-id <binary>
> 
> BTW, this would make INSTALL() depend on objdump or another tool.

If you specified to put the debug info in a separate file, yes. Where is the 
problem? CTest depends on gcov if I want coverage information. It depends on 
valgrind if I want memleak checks. If I want debug symbols, I would need to 
have obj* around. Since I can't get it in another way anyway, where is the 
problem?

> > [...] and place a link from
> > /usr/lib/debug/.build-id (or whereever) to the debug file
> 
> The fact that a binary contains a build ID does not necessarily mean
> that it is or has a debug info file; a build ID can also serve other
> identificatory purposes. So, this check will probably turn out to be
> insufficient since these cases can't be distinguished automatically.

The build id indicates where the debug info should go to if it is generated. 
If I don't specify to install debug information CMake doesn't need to check 
for it. If I enable this CMake can look and knows to which place to install 
the files. I still don't see any point where CMake wouldn't know the filenames 
to put the files to in advance (i.e. before it calls the tools that would 
actually do this).

> > So AFAICT there is no magic knowledge or searching for something
> > involved
> > at all.
> > 
> > Or am I getting something seriously wrong here?
> 
> To my mind, the discussion is not about debug-link vs. build-ID or
> objcopy vs. not-objcopy; these are just examples for the diversity
> of the debug info files' generation and processing. Instead, the
> discussion is actually about:
> 
> (1) Should CMake be taught to generate debug info files by itself?
>     While this is trivial with VS, it is - IMO - hardly feasible on
>     *nix in a manner that does not restrict the user's possibilities.
> 
> (2) Should CMake just install debug info files, the latters generated
>     before by the project? While this would probably be quite easy to
>     implement for VS, it is - IMO - hardly feasible on *nix without
>     (1) as CMake can't know the files' names and locations a priori.
>     Of course, one might agree on a convention that the debug info
>     file of a target xyz is to be named xyz.debug and placed next
>     to xyz.

Where is the problem in this? Doing the installation to the correct location 
according to the build id could be an (optional) add-on if a build-id is 
present.

> However, a possible approach to this topic I could imagine is the
> following: Add a new target property DEBUG_INFO_FILES[_<CONFIG>],
> perhaps initialized with $<TARGET_FILE_DIR:target>.pdb in VS and
> $<TARGET_FILE_DIR:target>.debug on *nix. If this property is set,
> this means that the denoted debug info files are to be generated,
> and INSTALL(TARGETS target DEBUG DESTINATION ...) would know where
> to find them. Regarding the Makefile generators, we would probably
> need an additional rule variable CMAKE_<LANG>_GENERATE_DEBUG_INFO
> or the like, but this would not account for an early role of the
> linker with potential user-supplied parameters. If you have any
> suggestions how to conceptually realize it, I'd be interested.

Sounds not too bad.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111014/3a38ae13/attachment.pgp>