During the last months, Hongxu Jia has proposed patches for how
to rework DEBUG_BUILD. It started out with the idea to collect
everything related to building for debug in a common file
(debug_build.inc), but has evolved into something more dramatic
where DEBUG_BUILD is replaced by the new variable DEBUG_OPTIMIZE.
While I understand the anticipation of being able to replace the
quite messy current solution related to DEBUG_BUILD with something
better, there are also concerns about us loosing features that it
currently supports.
This is my attempt at gathering my thoughts about how to work
with debug. I have gathered some use cases for what I believe
DEBUG_BUILD currently supports and that I expect to be able to
continue to use going forward.
First, it may be a good idea to discuss what building for debug
actually means. The obvious is to enable compiler/linker flags
that make it possible to debug the application in GDB. With the
current solution in OE Core, this is handled via the
FULL_OPTIMIZATION and DEBUG_OPTIMIZATION variables. But there is
more to it than that. Often there is also a need to build the
application differently, e.g., to enable extra debug messages.
This may require that, e.g., extra configuration flags are passed
to Meson.
It is also important to reflect on when (or for what) debug is
enabled. Speaking from my own experience, I typically only enable
debug for one application at a time. Possibly with the addition
of key dependencies that I expect that I need to step into during
debugging in GDB. Enabling debug for everything just because I
want to debug one application would just be a waste of time as
everything would need to be rebuilt.
Based on the above, I think it is a bad idea to rename DEBUG_BUILD
to DEBUG_OPTIMIZE. While DEBUG_BUILD may not be the best named
variable, it is an established API. And (at least to me) it is
about much more than just tweaking the compiler optimization.
Every time some of our developers come up with a new ingenious way
to enable extra debugging for their application, I always tell them
to use DEBUG_BUILD instead and key off of it. That makes it easy,
"if you want to debug an application, enable DEBUG_BUILD for it".
Below are some use cases, with examples of how to do it using the
current version of OE Core.
Enabling debug support:
* Enable debug for everything.
DEBUG_BUILD = "1"
* Enable debug for all target recipes.
DEBUG_BUILD:class-target = "1"
* Enable debug for all native recipes.
DEBUG_BUILD:class-native = "1"
* Enable debug for a specific recipe.
DEBUG_BUILD:pn-foo = "1"
Tweaking what happens when debug support is/isn't enabled:
* Use the debug buildtype with Meson recipes.
DEBUG_BUILD = "1"
* Build a Rust module for debug.
DEBUG_BUILD = "1"
* Add extra debug related compiler flags.
DEBUG_OPTIMIZATION += "-DDEBUG"
* Add extra non-debug related compiler flags.
FULL_OPTIMIZATION += "-DNDEBUG"
* Add extra debug related configuration flags.
EXTRA_OEMESON += "-Dprint_debug=${@oe.utils.vartrue('DEBUG_BUILD', 'true',
'false', d)}"
There is probably a lot more that can be said about how to prepare
for debugging. I hope this can be a starting point for some
discussions on how to proceed so that we can get a simpler
implementation without losing any important use cases.
//Peter
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2215):
https://lists.openembedded.org/g/openembedded-architecture/message/2215
Mute This Topic: https://lists.openembedded.org/mt/117513031/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
