All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mehdi AMINI <joker.eph@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] BR2_ENABLE_DEBUG is (incorrectly) using `Debug` for CMAKE_BUILD_TYPE instead of `RelWithDebInfo`
Date: Thu, 24 Aug 2017 18:47:33 -0700	[thread overview]
Message-ID: <CANF-O=Y3HWoBepd+AFZoe_Hm5o5+r1WC95Z8PeLrS6qpGvrdbQ@mail.gmail.com> (raw)
In-Reply-To: <d3f95fb4-acd1-83fa-e1fd-f33ed850249b@mind.be>

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>

  reply	other threads:[~2017-08-25  1:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2017-09-03 10:05     ` Mehdi AMINI

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANF-O=Y3HWoBepd+AFZoe_Hm5o5+r1WC95Z8PeLrS6qpGvrdbQ@mail.gmail.com' \
    --to=joker.eph@gmail.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.