From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4BCCAD4D.9040600@domain.hid> Date: Mon, 19 Apr 2010 21:21:49 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4BCC619E.2@domain.hid> <4BCC6CEE.70907@domain.hid> <4BCC6E3C.3090301@domain.hid> <4BCC7092.1030809@domain.hid> <4BCC71AF.4030903@domain.hid> <4BCC77BD.9040900@domain.hid> <4BCC78D5.3010405@domain.hid> <4BCC7D88.4070403@domain.hid> <1271693411.16659.128.camel@domain.hid> <4BCC814C.6050003@domain.hid> <4BCC8484.1020108@domain.hid> <4BCC9107.1080605@domain.hid> <4BCC9247.10709@domain.hid> <4BCC9628.7030809@domain.hid> <4BCC9ADA.2020909@domain.hid> <4BCC9D8D.10906@domain.hid> <4BCC9E81.8000209@domain.hid> <4BCC9F49.1010302@domain.hid> <4BCCA30A.7050208@domain.hid> <4BCCA3C0.7040209@domain.hid> <4BCCAA38.4070000@domain.hid> In-Reply-To: <4BCCAA38.4070000@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-core] [RFC] fix XENO_OPT_DEBUG bugs. List-Id: Xenomai life and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-core 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 >>>> #include >>>> >>>> #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.