Re: [CMake] Fwd: Save stripped debugging information
On 10/14/2011 12:58 AM, Rolf Eike Beer wrote: 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 mhertl...@online.dewrote: 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. Actually, my intention was to point out that generating debug info files on *nix is not equivalent to invoking objcopy; there're other methods, and we do not know which utility Y the toolchain X uses for this purpose. Apart from that, we can readily agree on the assumption that debug info files have certain names on *nix which are also known to CMake if this is believed to ease the further discussion. 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. Indeed, the problem w.r.t. the build ID is not an additional file, but the fact that (1) it must already be taken into account for the linking step, (2) must be provided with a user-supplied value and (3) the debug info file must be installed to or linked from a certain directory. If a cross-platform unification is to make sense, you must enhance the link step as well as the install step. Suppose this CMakeLists.txt excerpt: ADD_EXECUTABLE(main main.c) INSTALL(TARGETS main RUNTIME DESTINATION bin DEBUG DESTINATION ...) Suppose further a *nix user A wants to create and install a debug file for main with objcopy --only-keep-debug/--add-gnu-debuglink, whereas user B wants to do this with a build ID. What do you suggest that A and B should add to their respective CMakeLists.txt to accomplish their goals? Just conceptually, no implementation details. -optionally, and only on installation, check if the file has a build-id (using readelf, objdump or whatever) [...]
Re: [CMake] Fwd: Save stripped debugging information
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
mhertl...@online.dewrote:
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.
[...] 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, [...]
It's as optional as the usage of objcopy.
[...] and as far as I understand this the
primary use case is to find the debug symbols corresponding to an
executable. [...]
Right.
[...] The usual thing with gnu-debug-link is still done on those
binaries, so the build-id thing is on top of that. [...]
No, that's not true. Look at the following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(BUILDID C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
SET(BUILDID abcdef1234)
STRING(SUBSTRING ${BUILDID} 0 2 BUILDIDPREFIX)
STRING(SUBSTRING ${BUILDID} 2 8 BUILDIDSUFFIX)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c int main(void){return 0;}\n)
ADD_EXECUTABLE(main main.c)
SET_TARGET_PROPERTIES(main PROPERTIES
LINK_FLAGS -Wl,--build-id=0x${BUILDID})
ADD_CUSTOM_COMMAND(TARGET main POST_BUILD
COMMAND ${CMAKE_COMMAND} -E copy $TARGET_FILE:main
${CMAKE_BINARY_DIR}/main.debug
COMMAND ${CMAKE_STRIP} -g $TARGET_FILE:main)
INSTALL(FILES ${CMAKE_BINARY_DIR}/main.debug
DESTINATION ${CMAKE_BINARY_DIR}/.build-id/${BUILDIDPREFIX}
RENAME ${BUILDIDSUFFIX}.debug)
Configure with CMAKE_BUILD_TYPE==debug and build; subsequently, invoke
gdb -ex set debug-file-directory . -ex file main
from within CMAKE_BINARY_DIR, and you will read no debugging symbols
found as expected. Now, issue make install, re-invoke gdb and read:
Reading symbols from .../.build-id/ab/cdef1234.debug
As you can see, the debug info file is connected with the stripped
executable *solely* by the build ID; no objcopy in sight. In fact, the
build-ID method and the debug-link method are totally independent from
each other and can be used alternatively or jointly to connect a debug
info file with its executable; gdb does even check the build ID first.
[...] 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
As I have already outlined, objcopy is not
Re: [CMake] Fwd: Save stripped debugging information
On 10/13/2011 08:26 AM, Yuri Timenkov wrote:
See my comments inline.
I could make an implementation proposal, but I don't have time till the end
of November. So this discussion is quite pointless.
On Wed, Oct 12, 2011 at 3:02 PM, Michael Hertling mhertl...@online.dewrote:
On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
Hi Michael,
On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling mhertl...@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,
Not exactly. Output path and filename can be overridden with /IMPLIB linker
option. CMake just hard-codes this path.
That's what I had in mind; CMake can take care of import libraries with
regard to predictable names and locations since they are generated as a
by-product of the linking step, so they can flawlessly be installed by
the current means of the INSTALL() command. This does *not* apply to
debug info files on arbitrary platforms; their handling is just not
comparable with the import libraries' more regular one, IMO.
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?
It could be no-op if debug information is not separated, like installation
of LIBRARY part of library is no-op on Unix. Or it could install debug info
(separated with objcopy, as part of link step) as it is on VS. The latter
case is applicable if policy dictates to copy/strip debug info.
It's also possible to embed debug information into binary in VS (using /Z7
compiler switch, at least for static library).
All this relies on CMake's knowledge of debug info files - where
they reside and what their names are. That's somewhat trivial with
VS but rather difficult on *nix, and it's the latter which I aimed
at with specifying/parameterizing. Of course, we might agree on a
convention that the debug info file for target xyz has to be named
xyz.debug and placed next to xyz - howsoever it is generated - but
this does not account for the diverse methods to extract the debug
information and, moreover, there wouldn't be a point to use another
INSTALL() subcommand than INSTALL(FILES ...) on xyz.debug, AFAICS.
[...]
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.
IMO, this is already possible with installation components:
INSTALL(FILES debug-files DESTINATION ... COMPONENT debug)
You don't listen. The problem is not with components. [...]
Sorry if I don't have a clue - I use VS just occasionally - but what
exactly do you mean with devel package, e.g.? Usually, runtime
and devel are typical installation components that are defined
with INSTALL(... COMPONENT ...) and subsequently installed with
${CMAKE_COMMAND} -DCOMPONENT=component cmake_install.cmake,
and a component debug does indeed perfectly go with this.
[...] The problem is with
determining original path name for multi-configuration generators. I's
impossible to know what is debug-files.
It's impossible for *CMake* to know debug-files on *nix because their
are not generated as a by-product of the linking step with predictable
names. However, the *user* does know debug-files in any case - also
with multi-config generators - so it is well possible to install them
with INSTALL(FILES ...) by now, or is this proven wrong?
Admittedly, I'm still uncertain about our discussion's actual topic:
(1) Should CMake learn how to generate/recognize debug info files by
itself in a platform/generator-independent manner so they can be
simply installed
Re: [CMake] Fwd: Save stripped debugging information
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 mhertl...@online.dewrote: 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
Re: [CMake] Fwd: Save stripped debugging information
On 10/03/2011 09:18 AM, Yuri Timenkov wrote:
Hi Michael,
On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling mhertl...@online.dewrote:
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.
In order to not be misunderstood: I'm not opposed to introduce a new
INSTALL(TARGETS ... DEBUG DESTINATION ...)
subcommand, but it should definitely have a chance to work on all
platforms/generators and not limit the user's choices. If you have
an idea how such an enhancement may be designed, feel free to come
up with it, of course. Possibly, it might also be applicable to an
INSTALL(TARGETS ... PROFILE DESTINATION ...)
subcommand.
Adding objcopy/whatever to separate debug information to out-of-box CMake is
just one more step to unifying different platforms and generators.
On *nix, the extraction of debug information need not to be a step
that can be simply added. As I've already remarked in this thread,
it might involve the linker (build-ID approach), it might involve
supplementary tools (objcopy approach), it might involve both and
it might require the user to pass parameters (build-ID string).
[...]
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.
IMO, this is already possible with installation components:
INSTALL(FILES debug-files DESTINATION ... COMPONENT debug)
However, the basic problem remains: How does CMake get to know
the debug files on *non-VS* platforms? If this is once solved,
the debug files' pure installation should be fairly easy.
[...]
Regards,
Michael
On Oct 1, 2011 8:09 AM, Michael Hertling mhertl...@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_FLAGTARGET_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
Re: [CMake] Fwd: Save stripped debugging information
On 10/03/2011 09:18 AM, Yuri Timenkov wrote: Hi Michael, On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling mhertl...@online.dewrote: 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 -- 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
Re: [CMake] Fwd: Save stripped debugging information
Hi Michael,
On Sun, Oct 2, 2011 at 6:07 PM, Michael Hertling mhertl...@online.dewrote:
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 mhertl...@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_FLAGTARGET_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
Re: [CMake] Fwd: Save stripped debugging information
On 10/01/2011 01:35 PM, Rolf Eike Beer wrote:
Am Samstag 01 Oktober 2011, 06:11:44 schrieb Michael Hertling:
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.tx
t.
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_FLAGTARGET_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.
I don't see how this is really complicated. You call objcopy with some
options. The only things that change for each call are the name of the input
and the one of the output file. The input file is obviously already known,
the
output file is something like inputfilename.debug in the simple case.
You need a toolchain-specific rules for CMake to
-know if the toolchain has support
Re: [CMake] Fwd: Save stripped debugging information
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.
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?
[...] 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.
Regards,
Michael
On Oct 1, 2011 8:09 AM, Michael Hertling mhertl...@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_FLAGTARGET_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
Re: [CMake] Fwd: Save stripped debugging information
that's the problem: you don't know neither file name nor it's location,
especially in multi-configuration generators.
It's also bad idea to mix build and install steps. Install command doesn't
understand generators expressions.
If it were possible to emulate vs behavior for gcc things would be much
easier in some cases. However extracting debug info from binaries is
performed by packager (at least rpmbuild does this)
On Oct 1, 2011 8:09 AM, Michael Hertling mhertl...@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_FLAGTARGET_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
Re: [CMake] Fwd: Save stripped debugging information
Am Samstag 01 Oktober 2011, 06:11:44 schrieb Michael Hertling:
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.tx
t.
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_FLAGTARGET_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.
I don't see how this is really complicated. You call objcopy with some
options. The only things that change for each call are the name of the input
and the one of the output file. The input file is obviously already known, the
output file is something like inputfilename.debug in the simple case.
You need a toolchain-specific rules for CMake to
Re: [CMake] Fwd: Save stripped debugging information
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_FLAGTARGET_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
--
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
Re: [CMake] Fwd: Save stripped debugging information
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_FLAGTARGET_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
Re: [CMake] Fwd: Save stripped debugging information
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_FLAGTARGET_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 mhertl...@online.dewrote:
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
--
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
Re: [CMake] Fwd: Save stripped debugging information
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_FLAGTARGET_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.
And I agree that functionality like installing debug symbols in install()
rules out of box would be quite handy.
Regards,
Yuri
On Sat, Sep 24, 2011 at 4:02 AM, Michael Hertling mhertl...@online.dewrote:
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
--
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
--
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
Re: [CMake] Fwd: Save stripped debugging information
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
--
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
Re: [CMake] Fwd: Save stripped debugging information
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. Eike ___ 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
Re: [CMake] Fwd: Save stripped debugging information
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.
Eike
___
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
Why don't you invoke ${CMAKE_OBJCOPY} as a post build command?
___
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
Re: [CMake] Fwd: Save stripped debugging information
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
___
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
