[CMake] Fwd: Save stripped debugging information

[Rolf Eike Beer]

> 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. You _specify_ to objcopy where to put the debug file.
So CMake would need to specify this, i.e. can always know where these
files end up.

The build-id thing is optional, and as far as I understand this the
primary use case is to find the debug symbols corresponding to an
executable. The usual thing with gnu-debug-link is still done on those
binaries, so the build-id thing is on top of that. This would only affect
the install stage at all, i.e. if CMake would install these debug symbols
in the global debug directory.

So, to make things short:

-call objcopy with target filename and the output filename -> both come
from CMake, no magic
-optionally, and only on installation, check if the file has a build-id
(using readelf, objdump or whatever) and place a link from
/usr/lib/debug/.build-id (or whereever) to the debug file

So AFAICT there is no magic knowledge or searching for something involved
at all.

Or am I getting something seriously wrong here?

Eike