Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Jan Kiszka wrote:
>>>>> My compiler still complains about undefined 'y0' in the enabled case.
>>>>>
>>>>> I'll try to dig into a different direction now: Automatic generation
>>>>> during build. This is what the kernel does as well when the preprocessor
>>>>> gives up. Would even save the DECLARE and should make everyone happy.
>>>> No, please nothing like that.
>>> Because ... ?
>>>
>>> BTW, I'll extend the prepare stage. Defining the proper dependencies for
>>> build-time generation gets too hairy.
>>>
>>>> This one works for me:
>>>> #include <stdlib.h>
>>>> #include <stdio.h>
>>>>
>>>> #define __name2(a, b) a ## b
>>>> #define name2(a, b) __name2(a, b)
>>>>
>>>> #define DECLARE_ASSERT_SYMBOL(sym)                                      \
>>>>         static const int XENO_OPT_DEBUG_##sym = 0; \
>>>>         static const int CONFIG_XENO_OPT_DEBUG_##sym##0 = 0
>>>>
>>>> #define XENO_DEBUG(sym) \
>>>>         (name2(CONFIG_XENO_OPT_DEBUG_##sym,0) > XENO_OPT_DEBUG_##sym)
>>>>
>>>> #define XENO_ASSERT(subsystem,cond,action)  do { \
>>>>     if (unlikely(XENO_DEBUG(subsystem) && !(cond))) { \
>>>>         xnarch_trace_panic_freeze(); \
>>>>         xnlogerr("assertion failed at %s:%d (%s)\n", __FILE__, __LINE__, (#cond)); \
>>>>         xnarch_trace_panic_dump(); \
>>>>         action; \
>>>>     } \
>>>> } while(0)
>>>>
>>>> DECLARE_ASSERT_SYMBOL(NUCLEUS);
>>>>
>>>> int main(void)
>>>> {
>>>>         if (XENO_DEBUG(NUCLEUS))
>>>>                 printf("Hello\n");
>>>> }
>>>>
>>>> Please try and send me the result of pre-processing if
>>>> it does not work for you.
>>>>
>>> Find it attached.
>> It looks like you are defining CONFIG_XENO_OPT_DEBUG_NUCLEUS to be y
>> instead of 1.
> 
> Right, my bad.
> 
> Works now, just leaving a trace when optimization is off.

I believe the current approach would have the same problem. And in any
case the kernel is never compiled without optimization, some other
things break in that case.

> But as it still requires explicit declaration, I'm more in favor of
> (...)
> 
> diff --git a/scripts/prepare-kernel.sh b/scripts/prepare-kernel.sh
> index 24b1f17..d8038e0 100755
> Please let me know what precisely you dislike in this approach.

You have to re-run prepare-kernel when you modify the source.
And if you run it for every compilation, it wil slow the compilation down.
And you will have to add some tricks to avoid touching the generated
file if its contents did not change to avoid a full re-compilation.
And if you do all that you will end-up at best with 20 lines of shell.

The current candidate is 3 lines of C macro + 1 line per debug symbol.

I do not like dynamic sources generation. Especially when we have a
working solution based on C pre-processor macros.

-- 
					    Gilles.