[Mesa-dev] Let's talk about -DDEBUG

[Axel Davy]

On 13/12/2018 17:26, Jason Ekstrand wrote:
> On Thu, Dec 13, 2018 at 5:06 AM Eric Engestrom 
> <eric.engestrom at intel.com <mailto:eric.engestrom at intel.com>> wrote:
>
>     On Wednesday, 2018-12-12 15:24:25 -0800, Dylan Baker wrote:
>     > In the autotools discussion I've come to realize that we also
>     need to talk about
>     > the -DDEBUG guard. It seems that there are two different uses,
>     and thus two
>     > different asks about it:
>     >
>     > - Nine (and RadeonSI?) use -DDEBUG to hide generic debugging
>     > - NIR and Intel (at least) use -DDEBUG to hide really expensive
>     checks that are
>     >   useful, but necessarily tank performance.
>     >
>     > The first group would like -DDEBUG in debugoptimized builds, the
>     second
>     > obviously doesn't.
>     >
>     > Is the right solution to move the first group being !NDEBUG, or
>     would it be
>     > better to split DEBUG into two different defines such as
>     DEBUG_MESSAGES and
>     > EXPENSIVE_VALIDATION (paint the bikeshed whatever color you
>     like), with the
>     > first for both debug and debugoptimized and the second only in
>     debug builds?
>
>     Replacing DEBUG with !NDEBUG is obviously trivially simpler, but I
>     think
>     the right thing would be to split it into !NDEBUG and
>     EXPENSIVE_VALIDATION
>     (the color suits me just fine :P), as both solutions satisfy the first
>     group but only the latter solution satisfies the 2nd group.
>
>     I think a first pass might be to simply
>     s/DEBUG/EXPENSIVE_VALIDATION/ so
>     that it expresses the intent more clearly, with a prior patch to
>     convert
>     Nine and other obvious !NDEBUG candidates, then, later on, some of the
>     EXPENSIVE_VALIDATION can be promoted to !NDEBUG on a case-by-case
>     basis.
>
>
> I think this whole discussion is way over-thinking this. With autools, 
> we had two options: --enable-debug or not which, as I understand it, 
> corresponds to release and debug.  Great.  Now meson adds a new one.  
> Let's just pick something that makes sense and call it a day; it 
> really doesn't matter.  Anyone who wants more control can just set 
> their own CFLAGS.  Regardless of what we do, we're not really loosing 
> anything by doing this as people who build Nine today with 
> --enable-debug are getting an unoptimized build the same as they would 
> with -Dbuild-type=debug. Users/devs can also always set -Db_ndebug 
> manually to get the behavior that they want.
>
> I don't know that I have all that strong of a preference as I'm not 
> likely to use it anyway.  On the one hand, the name implies that it's 
> a debug build only optimized.  This is different than CMake's 
> RelWithDebugInfo which is clearly a release build with debug symbols.  
> Based on that naming, i'd say we should leave asserts on.
>
> I think the root of the issue is that different developers have tied 
> way too much stuff to -DDEBUG.  The Nine people can add a 
> -Dnine-logging=true flag that can turn on logging even in release 
> builds.  In the NIR-based drivers, we already have environment 
> variables to shut off NIR validation to make things go faster even in 
> debug builds.
>
> --Jason
>
Hi,


I agree with Jason that there seems to be a multitude of needs and that 
it may be hard to handle for all these needs in a simple way.

Devs who want to stress specific parts of their code can indeed use 
CFLAGS, and thus there isn't need to have a meson build mode for every 
specific need.

However I believe using a debug build option should be all that is 
needed for a user to help report bugs. If the user is investigating a 
crash, he wants to enable asserts and debug info. He may want to enable 
nine logging, etc.
Dev flags may change between releases, while the user would always have 
the same debug option to enable all it may need.

I think the autotools way was simple for the user, and the new meson way 
should be as simple. 'debugoptimized' is counter-intuitive for an user, 
who may expect all the mentioned debug info.

To me debugoptimized should be similar to debug, but with -O2.

Other dev specific debug options can be added with CFLAGS.



Axel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181213/711665f5/attachment.html>