From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs.
Date: Mon, 19 Apr 2010 21:37:43 +0200 [thread overview]
Message-ID: <4BCCB107.7090800@domain.hid> (raw)
In-Reply-To: <4BCCAD4D.9040600@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 3474 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2010-04-19 19:37 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 [this message]
2010-04-19 19:47 ` Gilles Chanteperdrix
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=4BCCB107.7090800@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=gilles.chanteperdrix@xenomai.org \
--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.