From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Date: Mon, 19 Apr 2010 21:47:23 +0200 [thread overview]
Message-ID: <4BCCB34B.8020609@domain.hid> (raw)
In-Reply-To: <4BCCB107.7090800@domain.hid>
Jan Kiszka wrote:
> 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.
When you use if(XENO_DEBUG(foo)) you are using the compiler, not the
preprocessor.
To see if there is a difference, you should try #if XENO_DEBUG(foo). And
from what I see, in that case I do not have any trace of anything generated.
>>> 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.
Not necessarily.
>> 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.
The current candidate would also detect the missing
DECLARE_ASSERT_SYMBOL in that case.
--
Gilles.
next prev parent reply other threads:[~2010-04-19 19:47 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 13:58 [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs Gilles Chanteperdrix
2010-04-19 14:00 ` [Xenomai-core] [PATCH] debug: fix direct references to CONFIG_XENO_OPT_DEBUG_* Gilles Chanteperdrix
2010-04-19 14:05 ` [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs Gilles Chanteperdrix
2010-04-19 14:47 ` Jan Kiszka
2010-04-19 14:52 ` Gilles Chanteperdrix
2010-04-19 15:02 ` Jan Kiszka
2010-04-19 15:07 ` Gilles Chanteperdrix
2010-04-19 15:33 ` Jan Kiszka
2010-04-19 15:37 ` Gilles Chanteperdrix
2010-04-19 15:58 ` Jan Kiszka
2010-04-19 16:10 ` Philippe Gerum
2010-04-19 16:14 ` Jan Kiszka
2010-04-19 16:25 ` Philippe Gerum
2010-04-19 16:43 ` Philippe Gerum
2010-04-19 17:22 ` Jan Kiszka
2010-04-19 17:23 ` Philippe Gerum
2010-04-19 17:27 ` Philippe Gerum
2010-04-19 16:27 ` Gilles Chanteperdrix
2010-04-19 17:21 ` Jan Kiszka
2010-04-19 17:26 ` Gilles Chanteperdrix
2010-04-19 17:43 ` Jan Kiszka
2010-04-19 17:56 ` Gilles Chanteperdrix
2010-04-19 18:03 ` Gilles Chanteperdrix
2010-04-19 18:14 ` Gilles Chanteperdrix
2010-04-19 18:18 ` Jan Kiszka
2010-04-19 18:22 ` Gilles Chanteperdrix
2010-04-19 18:38 ` Jan Kiszka
2010-04-19 18:41 ` Gilles Chanteperdrix
2010-04-19 19:08 ` Jan Kiszka
2010-04-19 19:21 ` Gilles Chanteperdrix
2010-04-19 19:37 ` Jan Kiszka
2010-04-19 19:47 ` Gilles Chanteperdrix [this message]
2010-04-19 20:08 ` Jan Kiszka
2010-04-19 20:33 ` Gilles Chanteperdrix
2010-04-19 19:55 ` Gilles Chanteperdrix
2010-04-20 12:48 ` Gilles Chanteperdrix
2010-04-20 14:02 ` Gilles Chanteperdrix
2010-04-19 15:06 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BCCB34B.8020609@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=jan.kiszka@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.