Would a variation on this proposal be to add app-specific NXAPP_DEBUGASSERT etc.? This would then be "global" but unique to apps, not overlap with O/S DEBUGASSERTs, and make for a simpler global search/replace of current DEBUGASSERT in apps, and just need a one-off new set of entries in the apps' Kconfig?

Over time, the NX apps debug "system" could be expanded/enhanced to allow app-by-app "APPNAME_ENABLE_DEBUG" that is similar to the OS DEBUG system, but would be quicker/easier to implement in one hit for now?

(Accidentally sent this before as a direct reply to Nathan: sorry!)

On 03/01/2024 16:43, Nathan Hartman wrote:
On Wed, Jan 3, 2024 at 11:22 AM Gregory Nutt <spudan...@gmail.com> wrote:
On 1/3/2024 10:11 AM, Fotis Panagiotopoulos wrote:
That would seem a little odd since there was a PR a few years ago to
change all instances of assert/ASSERT to DEBUGASSERT to save code size.

How is that so?

As I see here:
https://github.com/apache/nuttx/blob/master/include/assert.h#L122
assert defined exactly as DEBUGASSERT.

There shouldn't be any code size difference at all.
When CONFIG_DEBUG_ASSERTIONS is not defined, then all occurrences of
DEBUGASSERT compile to nothing (actually the current version compiles to
an expression that is optimized out):

     #undef DEBUGASSERT  /* Like ASSERT, but only if
     CONFIG_DEBUG_ASSERTIONS is defined */

     #ifdef CONFIG_DEBUG_ASSERTIONS
     #  define DEBUGASSERT(f) _ASSERT(f, __DEBUG_ASSERT_FILE__,
     __DEBUG_ASSERT_LINE__)
     #else
     #  define DEBUGASSERT(f) ((void)(1 || (f)))
     #endif

This value, ((void)(1 || (f))), is completely removed by the optimizer
because of short-circuiting and dead code removal.  So the code is much
smaller if CONFIG_DEBUG_ASSERTIONS is not enabled.  If DEBUGASSERT() is
replaced with assert() than that code bloat would be unconditional,
although somewhat less than when assertions are enabled.

This same kind of logic also applies to  DEBUGPANIC and DEBUGVERIFY.

Xiao Xiang made that change to reduce the size as needed by their
products.  He is the person you should be talking to.

Maybe we need NX_DEBUGASSERT, NX_DEBUGPANIC, NX_DEBUGVERIFY. The NX
prefix would make it more clear that this is NuttX-specific. These
would be used in the OS only, not in applications, and
CONFIG_DEBUG_ASSERTIONS would continue to control if these are real or
optimized out.

Applications that need their own specific, Kconfig-controlled debug
assertion, should define one themselves, and their own Kconfig to
optimize it out. Rationale: If you are debugging an application,
enable assertions only in that application, not everywhere throughout
the system.

Cheers
Nathan

Reply via email to