* [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` @ 2017-08-23 9:45 Mehdi AMINI 2017-08-23 16:46 ` Samuel Martin 2017-08-24 21:39 ` Arnout Vandecappelle 0 siblings, 2 replies; 7+ messages in thread From: Mehdi AMINI @ 2017-08-23 9:45 UTC (permalink / raw) To: buildroot Hi, I've been bitten by what I think is a surprising behavior of : https://bugs.busybox.net/show_bug.cgi?id=10246 Here is the documentation for BR2_ENABLE_DEBUG: config BR2_ENABLE_DEBUG bool "build packages with debugging symbols" help Build packages with debugging symbols enabled. All libraries and binaries in the 'staging' directory will have debugging symbols, which allows remote debugging even if libraries and binaries are stripped on the target. Whether libraries and binaries are stripped on the target is controlled by the BR2_STRIP_* options below. The option is supposed to enable debug symbols emission by the compiler. The description mentions that the purpose is to enable remote debugging using `staging` even after stripping the binaries in `target`. However, by using `Debug` as `CMAKE_BUILD_TYPE` the option is not orthogonal to other settings and have side-effects. In CMake, the CMAKE_BUILD_TYPE is not *only* controlling the debug info emission but also the optimization level for instance. Also, and with even more concerns, packages may use this to trigger other settings. It seems it has swing'd multiple times last year, first going from `Debug` to `RelWithDebInfo` here: http://lists.busybox.net/pipermail/buildroot/2016-June/163639.html and here http://lists.busybox.net/pipermail/buildroot/2016-July/165714.html ; and then back to `Debug` here: https://git.buildroot.org/buildroot/commit/package/pkg-cmake.mk?id=104bb29e0490bfb487e2e665448dd3ca07fcc2b5 (haven't found the mailing list discussion) The latter claims that switching from `Release` to `Debug` is "semantically closer" to the intent of the option in buildroot. If that is the case, the doc does not seem to reflect correctly this intent to me: I always want to build a "release" package, only to have debug-info emitted in my staging directory. All the other settings mentioned in this commit message (assertions enabled/disabled, optimization level, etc.) can be (and actually are I think) handled orthogonally using other CMake flags. Using the same CMAKE_BUILD_TYPE as a base and overriding individual setting seems like a more sane and robust approach to me. Two practical examples of packages that shows what can go wrong: 1) ceres-solver ( https://github.com/ceres-solver/ceres-solver ) When configured with CMAKE_BUILD_TYPE=Release, it'll generate: lib/libceres.a However with CMAKE_BUILD_TYPE=Debug we end up with: lib/libceres-debug.a 2) the LLVM compiler is doing special casing based on the value of CMAKE_BUILD_TYPE. For example: if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO") add_flag_if_supported("-gline-tables-only" GLINE_TABLES_ONLY) endif() # Use -O1 even in debug mode, otherwise sanitizers slowdown is too large. if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") add_flag_if_supported("-O1" O1) endif() Or also: if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) else() option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) endif() In my experience it has been quite common for CMake projects to use CMAKE_BUILD_TYPE to differentiate on more than just default optimization level. Best, -- Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170823/097c2f08/attachment.html> ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` 2017-08-23 9:45 [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` Mehdi AMINI @ 2017-08-23 16:46 ` Samuel Martin 2017-08-23 20:13 ` Mehdi AMINI 2017-08-24 21:39 ` Arnout Vandecappelle 1 sibling, 1 reply; 7+ messages in thread From: Samuel Martin @ 2017-08-23 16:46 UTC (permalink / raw) To: buildroot Hi Mehdi, On Wed, Aug 23, 2017 at 11:45 AM, Mehdi AMINI <joker.eph@gmail.com> wrote: > Hi, > > I've been bitten by what I think is a surprising behavior of : > https://bugs.busybox.net/show_bug.cgi?id=10246 > > Here is the documentation for BR2_ENABLE_DEBUG: > > config BR2_ENABLE_DEBUG > bool "build packages with debugging symbols" > help > Build packages with debugging symbols enabled. All libraries > and binaries in the 'staging' directory will have debugging > symbols, which allows remote debugging even if libraries and > binaries are stripped on the target. Whether libraries and > binaries are stripped on the target is controlled by the > BR2_STRIP_* options below. > > > The option is supposed to enable debug symbols emission by the compiler. The > description mentions that the purpose is to enable remote debugging using > `staging` even after stripping the binaries in `target`. > However, by using `Debug` as `CMAKE_BUILD_TYPE` the option is not orthogonal > to other settings and have side-effects. In CMake, the CMAKE_BUILD_TYPE is > not *only* controlling the debug info emission but also the optimization > level for instance. Also, and with even more concerns, packages may use this > to trigger other settings. > > It seems it has swing'd multiple times last year, first going from `Debug` > to `RelWithDebInfo` here: > http://lists.busybox.net/pipermail/buildroot/2016-June/163639.html and here > http://lists.busybox.net/pipermail/buildroot/2016-July/165714.html ; and > then back to `Debug` here: > https://git.buildroot.org/buildroot/commit/package/pkg-cmake.mk?id=104bb29e0490bfb487e2e665448dd3ca07fcc2b5 > (haven't found the mailing list discussion) > The latter claims that switching from `Release` to `Debug` is "semantically > closer" to the intent of the option in buildroot. If that is the case, the > doc does not seem to reflect correctly this intent to me: I always want to > build a "release" package, only to have debug-info emitted in my staging > directory. > You may not have the entire view that led to this, some valuable details are in this change: https://git.buildroot.org/buildroot/commit/?id=12494ef48f893684d0800e7f6fe39a2ceaed0451 > All the other settings mentioned in this commit message (assertions > enabled/disabled, optimization level, etc.) can be (and actually are I > think) handled orthogonally using other CMake flags. We went to these conclusions mostly by experiments, because CMake does not document the default values for all build type declinaison of flags :-/ https://cmake.org/cmake/help/v3.9/variable/CMAKE_BUILD_TYPE.html > > Using the same CMAKE_BUILD_TYPE as a base and overriding individual setting > seems like a more sane and robust approach to me. > > Two practical examples of packages that shows what can go wrong: > > 1) ceres-solver ( https://github.com/ceres-solver/ceres-solver ) > > When configured with CMAKE_BUILD_TYPE=Release, it'll generate: > > lib/libceres.a > > However with CMAKE_BUILD_TYPE=Debug we end up with: > > lib/libceres-debug.a > > > 2) the LLVM compiler is doing special casing based on the value of > CMAKE_BUILD_TYPE. For example: > > if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND > NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO") > add_flag_if_supported("-gline-tables-only" GLINE_TABLES_ONLY) > endif() > # Use -O1 even in debug mode, otherwise sanitizers slowdown is too > large. > if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") > add_flag_if_supported("-O1" O1) > endif() > > Or also: > > if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) > else() > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) > endif() > > > In my experience it has been quite common for CMake projects to use > CMAKE_BUILD_TYPE to differentiate on more than just default optimization > level. At the time the denounced changes were done, we did not have such cases in mind, nor to support, though they are legit. Enhancement welcome. Regards, -- Samuel ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` 2017-08-23 16:46 ` Samuel Martin @ 2017-08-23 20:13 ` Mehdi AMINI 2017-08-24 7:07 ` Samuel Martin 0 siblings, 1 reply; 7+ messages in thread From: Mehdi AMINI @ 2017-08-23 20:13 UTC (permalink / raw) To: buildroot Hi Samuel, Thanks for you answer. 2017-08-23 9:46 GMT-07:00 Samuel Martin <s.martin49@gmail.com>: > Hi Mehdi, > > On Wed, Aug 23, 2017 at 11:45 AM, Mehdi AMINI <joker.eph@gmail.com> wrote: > > Hi, > > > > I've been bitten by what I think is a surprising behavior of : > > https://bugs.busybox.net/show_bug.cgi?id=10246 > > > > Here is the documentation for BR2_ENABLE_DEBUG: > > > > config BR2_ENABLE_DEBUG > > bool "build packages with debugging symbols" > > help > > Build packages with debugging symbols enabled. All libraries > > and binaries in the 'staging' directory will have debugging > > symbols, which allows remote debugging even if libraries and > > binaries are stripped on the target. Whether libraries and > > binaries are stripped on the target is controlled by the > > BR2_STRIP_* options below. > > > > > > The option is supposed to enable debug symbols emission by the compiler. > The > > description mentions that the purpose is to enable remote debugging using > > `staging` even after stripping the binaries in `target`. > > However, by using `Debug` as `CMAKE_BUILD_TYPE` the option is not > orthogonal > > to other settings and have side-effects. In CMake, the CMAKE_BUILD_TYPE > is > > not *only* controlling the debug info emission but also the optimization > > level for instance. Also, and with even more concerns, packages may use > this > > to trigger other settings. > > > > It seems it has swing'd multiple times last year, first going from > `Debug` > > to `RelWithDebInfo` here: > > http://lists.busybox.net/pipermail/buildroot/2016-June/163639.html and > here > > http://lists.busybox.net/pipermail/buildroot/2016-July/165714.html ; and > > then back to `Debug` here: > > https://git.buildroot.org/buildroot/commit/package/pkg-cmake.mk?id= > 104bb29e0490bfb487e2e665448dd3ca07fcc2b5 > > (haven't found the mailing list discussion) > > The latter claims that switching from `Release` to `Debug` is > "semantically > > closer" to the intent of the option in buildroot. If that is the case, > the > > doc does not seem to reflect correctly this intent to me: I always want > to > > build a "release" package, only to have debug-info emitted in my staging > > directory. > > > > You may not have the entire view that led to this, some valuable > details are in this change: > https://git.buildroot.org/buildroot/commit/?id= > 12494ef48f893684d0800e7f6fe39a2ceaed0451 Yeah I didn't find this one before! If I read correctly what is described, this confirms that buildroot is able to override the default CMake value for the optimization level and debug, right? If so, then always using `-DCMAKE_BUILD_TYPE=Release` should be fine, correct? Why the switch to a different -DCMAKE_BUILD_TYPE? > > > > All the other settings mentioned in this commit message (assertions > > enabled/disabled, optimization level, etc.) can be (and actually are I > > think) handled orthogonally using other CMake flags. > > We went to these conclusions mostly by experiments, because CMake does > not document the default values for all build type declinaison of > flags :-/ > https://cmake.org/cmake/help/v3.9/variable/CMAKE_BUILD_TYPE.html Especially it is toolchain dependent (and not guarantee to stay constant across release I guess). I assume you care the most about the GNU toolchain: https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake#L43 But if some projects are building GPU code: https://github.com/Kitware/CMake/blob/master/Modules/Compiler/NVIDIA-CUDA.cmake > > > > Using the same CMAKE_BUILD_TYPE as a base and overriding individual > setting > > seems like a more sane and robust approach to me. > > > > Two practical examples of packages that shows what can go wrong: > > > > 1) ceres-solver ( https://github.com/ceres-solver/ceres-solver ) > > > > When configured with CMAKE_BUILD_TYPE=Release, it'll generate: > > > > lib/libceres.a > > > > However with CMAKE_BUILD_TYPE=Debug we end up with: > > > > lib/libceres-debug.a > > > > > > 2) the LLVM compiler is doing special casing based on the value of > > CMAKE_BUILD_TYPE. For example: > > > > if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND > > NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO") > > add_flag_if_supported("-gline-tables-only" GLINE_TABLES_ONLY) > > endif() > > # Use -O1 even in debug mode, otherwise sanitizers slowdown is too > > large. > > if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") > > add_flag_if_supported("-O1" O1) > > endif() > > > > Or also: > > > > if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) > > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) > > else() > > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) > > endif() > > > > > > In my experience it has been quite common for CMake projects to use > > CMAKE_BUILD_TYPE to differentiate on more than just default optimization > > level. > > At the time the denounced changes were done, we did not have such > cases in mind, nor to support, though they are legit. > Enhancement welcome > So what do you think about always using -DCMAKE_BUILD_TYPE=Release instead? Best, -- Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170823/ff5dbfef/attachment.html> ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` 2017-08-23 20:13 ` Mehdi AMINI @ 2017-08-24 7:07 ` Samuel Martin 0 siblings, 0 replies; 7+ messages in thread From: Samuel Martin @ 2017-08-24 7:07 UTC (permalink / raw) To: buildroot Hi Mehdi, On Wed, Aug 23, 2017 at 10:13 PM, Mehdi AMINI <joker.eph@gmail.com> wrote: > Hi Samuel, > > Thanks for you answer. > > 2017-08-23 9:46 GMT-07:00 Samuel Martin <s.martin49@gmail.com>: >> >> Hi Mehdi, >> >> On Wed, Aug 23, 2017 at 11:45 AM, Mehdi AMINI <joker.eph@gmail.com> wrote: >> > Hi, >> > >> > I've been bitten by what I think is a surprising behavior of : >> > https://bugs.busybox.net/show_bug.cgi?id=10246 >> > >> > Here is the documentation for BR2_ENABLE_DEBUG: >> > >> > config BR2_ENABLE_DEBUG >> > bool "build packages with debugging symbols" >> > help >> > Build packages with debugging symbols enabled. All libraries >> > and binaries in the 'staging' directory will have debugging >> > symbols, which allows remote debugging even if libraries and >> > binaries are stripped on the target. Whether libraries and >> > binaries are stripped on the target is controlled by the >> > BR2_STRIP_* options below. >> > >> > >> > The option is supposed to enable debug symbols emission by the compiler. >> > The >> > description mentions that the purpose is to enable remote debugging >> > using >> > `staging` even after stripping the binaries in `target`. >> > However, by using `Debug` as `CMAKE_BUILD_TYPE` the option is not >> > orthogonal >> > to other settings and have side-effects. In CMake, the CMAKE_BUILD_TYPE >> > is >> > not *only* controlling the debug info emission but also the optimization >> > level for instance. Also, and with even more concerns, packages may use >> > this >> > to trigger other settings. >> > >> > It seems it has swing'd multiple times last year, first going from >> > `Debug` >> > to `RelWithDebInfo` here: >> > http://lists.busybox.net/pipermail/buildroot/2016-June/163639.html and >> > here >> > http://lists.busybox.net/pipermail/buildroot/2016-July/165714.html ; and >> > then back to `Debug` here: >> > >> > https://git.buildroot.org/buildroot/commit/package/pkg-cmake.mk?id=104bb29e0490bfb487e2e665448dd3ca07fcc2b5 >> > (haven't found the mailing list discussion) >> > The latter claims that switching from `Release` to `Debug` is >> > "semantically >> > closer" to the intent of the option in buildroot. If that is the case, >> > the >> > doc does not seem to reflect correctly this intent to me: I always want >> > to >> > build a "release" package, only to have debug-info emitted in my staging >> > directory. >> > >> >> You may not have the entire view that led to this, some valuable >> details are in this change: >> >> https://git.buildroot.org/buildroot/commit/?id=12494ef48f893684d0800e7f6fe39a2ceaed0451 > > > Yeah I didn't find this one before! > If I read correctly what is described, this confirms that buildroot is able > to override the default CMake value for the optimization level and debug, > right? Exactly > If so, then always using `-DCMAKE_BUILD_TYPE=Release` should be fine, > correct? Yes > Why the switch to a different -DCMAKE_BUILD_TYPE? Certainly to be less misleading when people looks at the configure command line. But the way we are doing this the CMAKE_BUILD_TYPE value does not reaily matter from our point of view. Though I agree, it may have some impact if the project cmake code is sensitive to it and uses it in a non-standard/expected fashion. > > >> >> >> >> > All the other settings mentioned in this commit message (assertions >> > enabled/disabled, optimization level, etc.) can be (and actually are I >> > think) handled orthogonally using other CMake flags. >> >> We went to these conclusions mostly by experiments, because CMake does >> not document the default values for all build type declinaison of >> flags :-/ >> https://cmake.org/cmake/help/v3.9/variable/CMAKE_BUILD_TYPE.html > > > Especially it is toolchain dependent (and not guarantee to stay constant > across release I guess). > I assume you care the most about the GNU toolchain: > https://github.com/Kitware/CMake/blob/master/Modules/Compiler/GNU.cmake#L43 Yes mostly > > But if some projects are building GPU code: > https://github.com/Kitware/CMake/blob/master/Modules/Compiler/NVIDIA-CUDA.cmake I'm not sure what take precedence between the initial value of CMAKE_C_FLAGS and CMAKE_C_FLAGS_INIT > > >> >> > >> > Using the same CMAKE_BUILD_TYPE as a base and overriding individual >> > setting >> > seems like a more sane and robust approach to me. >> > >> > Two practical examples of packages that shows what can go wrong: >> > >> > 1) ceres-solver ( https://github.com/ceres-solver/ceres-solver ) >> > >> > When configured with CMAKE_BUILD_TYPE=Release, it'll generate: >> > >> > lib/libceres.a >> > >> > However with CMAKE_BUILD_TYPE=Debug we end up with: >> > >> > lib/libceres-debug.a >> > >> > >> > 2) the LLVM compiler is doing special casing based on the value of >> > CMAKE_BUILD_TYPE. For example: >> > >> > if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND >> > NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO") >> > add_flag_if_supported("-gline-tables-only" GLINE_TABLES_ONLY) >> > endif() >> > # Use -O1 even in debug mode, otherwise sanitizers slowdown is too >> > large. >> > if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") >> > add_flag_if_supported("-O1" O1) >> > endif() >> > >> > Or also: >> > >> > if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) >> > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) >> > else() >> > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) >> > endif() >> > >> > >> > In my experience it has been quite common for CMake projects to use >> > CMAKE_BUILD_TYPE to differentiate on more than just default optimization >> > level. >> >> At the time the denounced changes were done, we did not have such >> cases in mind, nor to support, though they are legit. >> Enhancement welcome > > > So what do you think about always using -DCMAKE_BUILD_TYPE=Release instead? Since Buildroot set what it prefer, workarounding the CMake build type feature, I don't see anything preventing from always using the release build type. > > Best, > > -- > Mehdi > Regards, -- Samuel ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` 2017-08-23 9:45 [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` Mehdi AMINI 2017-08-23 16:46 ` Samuel Martin @ 2017-08-24 21:39 ` Arnout Vandecappelle 2017-08-25 1:47 ` Mehdi AMINI 1 sibling, 1 reply; 7+ messages in thread From: Arnout Vandecappelle @ 2017-08-24 21:39 UTC (permalink / raw) To: buildroot On 23-08-17 11:45, Mehdi AMINI wrote: [snip] > Two practical examples of packages that shows what can go wrong: > > 1) ceres-solver ( https://github.com/ceres-solver/ceres-solver ) > > When configured with CMAKE_BUILD_TYPE=Release, it'll generate: > > lib/libceres.a > > However with CMAKE_BUILD_TYPE=Debug we end up with: > > lib/libceres-debug.a > > > 2) the LLVM compiler is doing special casing based on the value of > CMAKE_BUILD_TYPE. For example: > > if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND > NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO") > add_flag_if_supported("-gline-tables-only" GLINE_TABLES_ONLY) > endif() > # Use -O1 even in debug mode, otherwise sanitizers slowdown is too large. > if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") > add_flag_if_supported("-O1" O1) > endif() > > Or also: > > if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) > else() > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) > endif() > > > In my experience it has been quite common for CMake projects to use > CMAKE_BUILD_TYPE to differentiate on more than just default optimization level. I think this is exactly why we should use Debug/Release instead of always using Release: the CmakeLists.txt may enable some other things conditional on debug, and when you choose BR2_ENABLE_DEBUG, you typically want those other things. Like the assertions in LLVM. The ceres solver is something else. That package is just doing the wrong thing. It needs to be patched to remove that -debug suffix. We do something similar for synergy, for instance. Regards, Arnout -- Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` 2017-08-24 21:39 ` Arnout Vandecappelle @ 2017-08-25 1:47 ` Mehdi AMINI 2017-09-03 10:05 ` Mehdi AMINI 0 siblings, 1 reply; 7+ messages in thread From: Mehdi AMINI @ 2017-08-25 1:47 UTC (permalink / raw) To: buildroot 2017-08-24 14:39 GMT-07:00 Arnout Vandecappelle <arnout@mind.be>: > > > On 23-08-17 11:45, Mehdi AMINI wrote: > [snip] > > Two practical examples of packages that shows what can go wrong: > > > > 1) ceres-solver ( https://github.com/ceres-solver/ceres-solver ) > > > > When configured with CMAKE_BUILD_TYPE=Release, it'll generate: > > > > lib/libceres.a > > > > However with CMAKE_BUILD_TYPE=Debug we end up with: > > > > lib/libceres-debug.a > > > > > > 2) the LLVM compiler is doing special casing based on the value of > > CMAKE_BUILD_TYPE. For example: > > > > if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND > > NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO") > > add_flag_if_supported("-gline-tables-only" GLINE_TABLES_ONLY) > > endif() > > # Use -O1 even in debug mode, otherwise sanitizers slowdown is too > large. > > if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") > > add_flag_if_supported("-O1" O1) > > endif() > > > > Or also: > > > > if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) > > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) > > else() > > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) > > endif() > > > > > > In my experience it has been quite common for CMake projects to use > > CMAKE_BUILD_TYPE to differentiate on more than just default optimization > level. > > I think this is exactly why we should use Debug/Release instead of always > using > Release: the CmakeLists.txt may enable some other things conditional on > debug, > and when you choose BR2_ENABLE_DEBUG, you typically want those other > things. > Like the assertions in LLVM. > This is not what the documentation / description of the option says I believe. I wouldn't expect the generated code to be any different when enabling BR2_ENABLE_DEBUG personally (other than the added DWARF section). My reading of the description is that I should be able to turn it on and the binaries in the target directory should be bit-to-bit identical (assuming the rest of the build and the compiler is deterministic). If that's not the intent behind BR2_ENABLE_DEBUG, it seems to me that another option could be useful to provide exactly this mode: getting debug info in the staging directory without affecting anything in the target. Hope this makes sense. Best, -- Mehdi > > The ceres solver is something else. That package is just doing the wrong > thing. > It needs to be patched to remove that -debug suffix. We do something > similar for > synergy, for instance. > > Regards, > Arnout > > > -- > Arnout Vandecappelle arnout at mind be > Senior Embedded Software Architect +32-16-286500 > Essensium/Mind http://www.mind.be > G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven > LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle > GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170824/decb0c19/attachment.html> ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` 2017-08-25 1:47 ` Mehdi AMINI @ 2017-09-03 10:05 ` Mehdi AMINI 0 siblings, 0 replies; 7+ messages in thread From: Mehdi AMINI @ 2017-09-03 10:05 UTC (permalink / raw) To: buildroot Hi all, Patch attached! (Let me know if I should start a separate thread instead) Best, -- Mehdi 2017-08-24 18:47 GMT-07:00 Mehdi AMINI <joker.eph@gmail.com>: > > > 2017-08-24 14:39 GMT-07:00 Arnout Vandecappelle <arnout@mind.be>: > >> >> >> On 23-08-17 11:45, Mehdi AMINI wrote: >> [snip] >> > Two practical examples of packages that shows what can go wrong: >> > >> > 1) ceres-solver ( https://github.com/ceres-solver/ceres-solver ) >> > >> > When configured with CMAKE_BUILD_TYPE=Release, it'll generate: >> > >> > lib/libceres.a >> > >> > However with CMAKE_BUILD_TYPE=Debug we end up with: >> > >> > lib/libceres-debug.a >> > >> > >> > 2) the LLVM compiler is doing special casing based on the value of >> > CMAKE_BUILD_TYPE. For example: >> > >> > if (NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" AND >> > NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "RELWITHDEBINFO") >> > add_flag_if_supported("-gline-tables-only" GLINE_TABLES_ONLY) >> > endif() >> > # Use -O1 even in debug mode, otherwise sanitizers slowdown is too >> large. >> > if (uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG") >> > add_flag_if_supported("-O1" O1) >> > endif() >> > >> > Or also: >> > >> > if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL "DEBUG" ) >> > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" OFF) >> > else() >> > option(LLVM_ENABLE_ASSERTIONS "Enable assertions" ON) >> > endif() >> > >> > >> > In my experience it has been quite common for CMake projects to use >> > CMAKE_BUILD_TYPE to differentiate on more than just default >> optimization level. >> >> I think this is exactly why we should use Debug/Release instead of >> always using >> Release: the CmakeLists.txt may enable some other things conditional on >> debug, >> and when you choose BR2_ENABLE_DEBUG, you typically want those other >> things. >> Like the assertions in LLVM. >> > > This is not what the documentation / description of the option says I > believe. I wouldn't expect the generated code to be any different when > enabling BR2_ENABLE_DEBUG personally (other than the added DWARF section). > My reading of the description is that I should be able to turn it on and > the binaries in the target directory should be bit-to-bit identical > (assuming the rest of the build and the compiler is deterministic). > > If that's not the intent behind BR2_ENABLE_DEBUG, it seems to me that > another option could be useful to provide exactly this mode: getting debug > info in the staging directory without affecting anything in the target. > > Hope this makes sense. > > Best, > > -- > Mehdi > > > >> >> The ceres solver is something else. That package is just doing the wrong >> thing. >> It needs to be patched to remove that -debug suffix. We do something >> similar for >> synergy, for instance. >> >> Regards, >> Arnout >> >> >> -- >> Arnout Vandecappelle arnout at mind be >> Senior Embedded Software Architect +32-16-286500 >> Essensium/Mind http://www.mind.be >> G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven >> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle >> GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170903/9c383c56/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-BR2_ENABLE_DEBUG-handling-for-cmake-packages.patch Type: application/octet-stream Size: 2097 bytes Desc: not available URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170903/9c383c56/attachment.obj> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-09-03 10:05 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-08-23 9:45 [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo` Mehdi AMINI 2017-08-23 16:46 ` Samuel Martin 2017-08-23 20:13 ` Mehdi AMINI 2017-08-24 7:07 ` Samuel Martin 2017-08-24 21:39 ` Arnout Vandecappelle 2017-08-25 1:47 ` Mehdi AMINI 2017-09-03 10:05 ` Mehdi AMINI
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.