Gilles Chanteperdrix wrote:
> 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

Nope, it's a pure preprocessor approach.

> 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.

Normally, you have to anyway as you add some header or some other source
file during this process.

> 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.

The changes to assert.h do not matter that much. More important is that
you do not need to bother about adding the declare somewhere.

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

My prepare-kernel approach also detects stall debug stuff: The uitron
use of XENO_DEBUG is not backed by any config option.

Jan