[Xenomai-core] get the simulator running...

[Xenomai-core] get the simulator running...

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 1308 bytes --]

Philippe,

here are some patches and comments on the simulator "quick"-start
process. I guess the patches are due to latest changes in trunk, and I
cannot guarantee that they are clean - but the simulator compiles now.

Regarding the rest of its build and start process: There are two hidden
requirements, namely gcc < 4 (due to -fwritable-strings) and gdb 5.x. A
note in sim/README about them would be great. Or do you have a fix for
those issues scheduled?

Well, once you got this far (i.e. the xenoscope is built and an ancient
gdb has been prepared), the next step is to produce a test program. Am I
overseeing some example? Fortunately, I had that demo I once produced
(last year), but that one was easier to build. I first had to drag in
the libs and includes of both the simulator and a regular xenomai
installation (I think to remember this once worked without this
add-ons). Then I need this additional trick in the simulators include dir:

mkdir asm
ln -s <xeno-inst-dir>/include/asm-sim asm/xenomai

This maps #include <asm/xenomai/system.h> to the correct "arch".
Shouldn't this be created automatically during the simulator
installation? Or is something else broken on my box?

In case there is no demo prepared, I could pack my own tiny stuff and
submit it.

Jan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: sim-fixes.patch --]
[-- Type: text/x-patch; name="sim-fixes.patch", Size: 2631 bytes --]

Index: ksrc/skins/vxworks/msgQLib.c
===================================================================
--- ksrc/skins/vxworks/msgQLib.c	(Revision 742)
+++ ksrc/skins/vxworks/msgQLib.c	(Arbeitskopie)
@@ -199,7 +199,7 @@
     appendq(&wind_msgq_q, &queue->link);
     xnlock_put_irqrestore(&nklock, s);
     
-#ifdef CONFIG_XENO_OPT_REGISTRY
+#ifdef CONFIG_XENO_EXPORT_REGISTRY
     sprintf(queue->name,"mq%lu",msgq_ids++);
 
     if (xnregistry_enter(queue->name,queue,&queue->handle,&msgq_pnode))
@@ -208,7 +208,7 @@
 	msgQDelete((MSG_Q_ID)queue);
 	return 0;
 	}
-#endif /* CONFIG_XENO_OPT_REGISTRY */
+#endif /* CONFIG_XENO_EXPORT_REGISTRY */
 
     return (MSG_Q_ID) queue;
 }
Index: ksrc/skins/vxworks/wdLib.c
===================================================================
--- ksrc/skins/vxworks/wdLib.c	(Revision 742)
+++ ksrc/skins/vxworks/wdLib.c	(Arbeitskopie)
@@ -123,7 +123,7 @@
     appendq(&wind_wd_q,&wd->link);
     xnlock_put_irqrestore(&nklock, s);
 
-#ifdef CONFIG_XENO_OPT_REGISTRY
+#ifdef CONFIG_XENO_EXPORT_REGISTRY
     sprintf(wd->name,"wd%lu",wd_ids++);
 
     if (xnregistry_enter(wd->name,wd,&wd->handle,&wd_pnode))
@@ -132,7 +132,7 @@
 	wdDelete((WDOG_ID)wd);
 	return 0;
 	}
-#endif /* CONFIG_XENO_OPT_REGISTRY */
+#endif /* CONFIG_XENO_EXPORT_REGISTRY */
 
     return (WDOG_ID) wd;
 }
Index: ksrc/skins/vxworks/semLib.c
===================================================================
--- ksrc/skins/vxworks/semLib.c	(Revision 742)
+++ ksrc/skins/vxworks/semLib.c	(Arbeitskopie)
@@ -479,7 +479,7 @@
     xnlock_get_irqsave(&nklock, s);
     appendq(&wind_sem_q,&sem->link);
     xnlock_put_irqrestore(&nklock, s);
-#ifdef CONFIG_XENO_OPT_REGISTRY
+#ifdef CONFIG_XENO_EXPORT_REGISTRY
     sprintf(sem->name,"sem%lu",sem_ids++);
 
     if (xnregistry_enter(sem->name,sem,&sem->handle,&sem_pnode))
@@ -488,7 +488,7 @@
 	semDelete((SEM_ID)sem);
 	return 0;
 	}
-#endif /* CONFIG_XENO_OPT_REGISTRY */
+#endif /* CONFIG_XENO_EXPORT_REGISTRY */
 
     return (SEM_ID) sem;
 }
Index: include/asm-sim/system.h
===================================================================
--- include/asm-sim/system.h	(Revision 742)
+++ include/asm-sim/system.h	(Arbeitskopie)
@@ -80,6 +80,7 @@
 
 #define XNARCH_DEFAULT_TICK         10000000 /* ns, i.e. 10ms */
 #define XNARCH_HOST_TICK            0 /* No host ticking service. */
+#define HZ                          0 /* dummy define for HZ */
 
 #define XNARCH_THREAD_STACKSZ 0 /* Let the simulator choose. */
 #define XNARCH_ROOT_STACKSZ   0	/* Only a placeholder -- no stack */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] get the simulator running...

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Philippe,
 > 
 > here are some patches and comments on the simulator "quick"-start
 > process. I guess the patches are due to latest changes in trunk, and I
 > cannot guarantee that they are clean - but the simulator compiles now.
 > 
 > Regarding the rest of its build and start process: There are two hidden
 > requirements, namely gcc < 4 (due to -fwritable-strings) and gdb 5.x. A
 > note in sim/README about them would be great. Or do you have a fix for
 > those issues scheduled?

which version of gdb did you try ? version 6.3 works here.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] get the simulator running...

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Philippe,
>  > 
>  > here are some patches and comments on the simulator "quick"-start
>  > process. I guess the patches are due to latest changes in trunk, and I
>  > cannot guarantee that they are clean - but the simulator compiles now.
>  > 
>  > Regarding the rest of its build and start process: There are two hidden
>  > requirements, namely gcc < 4 (due to -fwritable-strings) and gdb 5.x. A
>  > note in sim/README about them would be great. Or do you have a fix for
>  > those issues scheduled?
> 
> which version of gdb did you try ? version 6.3 works here.
> 

Same version (6.3, OpenSuSE 10.0), but it doesn't work while 5.3 is
fine. Strange.

The effect is that I can load the program with full tracing depth, it
stops in mvm_root(), but I cannot step further (simulator hangs then). I
noticed that my own 5.3 gdb compilation is 10M heavy, while SuSE's is
only about 2M. Could have anything critical been switched off by the
distributor?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[Xenomai-core] Re: get the simulator running...

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe,
> 
> here are some patches and comments on the simulator "quick"-start
> process. I guess the patches are due to latest changes in trunk, and I
> cannot guarantee that they are clean - but the simulator compiles now.
> 
> Regarding the rest of its build and start process: There are two hidden
> requirements, namely gcc < 4 (due to -fwritable-strings)

Normally, availability of --fwritable-strings should be auto-detected by 
the configure script. So there is something wrong going there, I will 
look at it.

  and gdb 5.x. A

I've been unlucky with GDB 6.x too, but did not check the latest 
release; I'm currently using 5.3 when running simulations.

> note in sim/README about them would be great. Or do you have a fix for
> those issues scheduled?

--fwritable-strings should be fixed. I'm not sure if the requirement for 
GDB 5.x still applies though.
> 
> Well, once you got this far (i.e. the xenoscope is built and an ancient
> gdb has been prepared), the next step is to produce a test program. Am I
> overseeing some example?

Look into ksrc/skins/{vxworks,psos+}/demos. The Makefile also produces a 
simulation executable for satch. Then run "xenoscope satch_sim"

  Fortunately, I had that demo I once produced
> (last year), but that one was easier to build. I first had to drag in
> the libs and includes of both the simulator and a regular xenomai
> installation (I think to remember this once worked without this
> add-ons). Then I need this additional trick in the simulators include dir:
> 
> mkdir asm
> ln -s <xeno-inst-dir>/include/asm-sim asm/xenomai
> 
> This maps #include <asm/xenomai/system.h> to the correct "arch".
> Shouldn't this be created automatically during the simulator
> installation? Or is something else broken on my box?
> 

You clearly should not need this trick to compile apps against the 
simulation environment; the instrumenter (gcic) sets the proper flags. 
I'm going to rebuild one and let you know.

> In case there is no demo prepared, I could pack my own tiny stuff and
> submit it.
> 
> Jan
> 
> 
> ------------------------------------------------------------------------
> 
> Index: ksrc/skins/vxworks/msgQLib.c
> ===================================================================
> --- ksrc/skins/vxworks/msgQLib.c	(Revision 742)
> +++ ksrc/skins/vxworks/msgQLib.c	(Arbeitskopie)
> @@ -199,7 +199,7 @@
>      appendq(&wind_msgq_q, &queue->link);
>      xnlock_put_irqrestore(&nklock, s);
>      
> -#ifdef CONFIG_XENO_OPT_REGISTRY
> +#ifdef CONFIG_XENO_EXPORT_REGISTRY
>      sprintf(queue->name,"mq%lu",msgq_ids++);
>  
>      if (xnregistry_enter(queue->name,queue,&queue->handle,&msgq_pnode))
> @@ -208,7 +208,7 @@
>  	msgQDelete((MSG_Q_ID)queue);
>  	return 0;
>  	}
> -#endif /* CONFIG_XENO_OPT_REGISTRY */
> +#endif /* CONFIG_XENO_EXPORT_REGISTRY */
>  
>      return (MSG_Q_ID) queue;
>  }
> Index: ksrc/skins/vxworks/wdLib.c
> ===================================================================
> --- ksrc/skins/vxworks/wdLib.c	(Revision 742)
> +++ ksrc/skins/vxworks/wdLib.c	(Arbeitskopie)
> @@ -123,7 +123,7 @@
>      appendq(&wind_wd_q,&wd->link);
>      xnlock_put_irqrestore(&nklock, s);
>  
> -#ifdef CONFIG_XENO_OPT_REGISTRY
> +#ifdef CONFIG_XENO_EXPORT_REGISTRY
>      sprintf(wd->name,"wd%lu",wd_ids++);
>  
>      if (xnregistry_enter(wd->name,wd,&wd->handle,&wd_pnode))
> @@ -132,7 +132,7 @@
>  	wdDelete((WDOG_ID)wd);
>  	return 0;
>  	}
> -#endif /* CONFIG_XENO_OPT_REGISTRY */
> +#endif /* CONFIG_XENO_EXPORT_REGISTRY */
>  
>      return (WDOG_ID) wd;
>  }
> Index: ksrc/skins/vxworks/semLib.c
> ===================================================================
> --- ksrc/skins/vxworks/semLib.c	(Revision 742)
> +++ ksrc/skins/vxworks/semLib.c	(Arbeitskopie)
> @@ -479,7 +479,7 @@
>      xnlock_get_irqsave(&nklock, s);
>      appendq(&wind_sem_q,&sem->link);
>      xnlock_put_irqrestore(&nklock, s);
> -#ifdef CONFIG_XENO_OPT_REGISTRY
> +#ifdef CONFIG_XENO_EXPORT_REGISTRY
>      sprintf(sem->name,"sem%lu",sem_ids++);
>  
>      if (xnregistry_enter(sem->name,sem,&sem->handle,&sem_pnode))
> @@ -488,7 +488,7 @@
>  	semDelete((SEM_ID)sem);
>  	return 0;
>  	}
> -#endif /* CONFIG_XENO_OPT_REGISTRY */
> +#endif /* CONFIG_XENO_EXPORT_REGISTRY */
>  
>      return (SEM_ID) sem;
>  }
> Index: include/asm-sim/system.h
> ===================================================================
> --- include/asm-sim/system.h	(Revision 742)
> +++ include/asm-sim/system.h	(Arbeitskopie)
> @@ -80,6 +80,7 @@
>  
>  #define XNARCH_DEFAULT_TICK         10000000 /* ns, i.e. 10ms */
>  #define XNARCH_HOST_TICK            0 /* No host ticking service. */
> +#define HZ                          0 /* dummy define for HZ */
>  
>  #define XNARCH_THREAD_STACKSZ 0 /* Let the simulator choose. */
>  #define XNARCH_ROOT_STACKSZ   0	/* Only a placeholder -- no stack */


-- 

Philippe.

Re: [Xenomai-core] Re: get the simulator running...

[Philippe Gerum]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe,
>>
>> here are some patches and comments on the simulator "quick"-start
>> process. I guess the patches are due to latest changes in trunk, and I
>> cannot guarantee that they are clean - but the simulator compiles now.
>>
>> Regarding the rest of its build and start process: There are two hidden
>> requirements, namely gcc < 4 (due to -fwritable-strings)
> 
> 
> Normally, availability of --fwritable-strings should be auto-detected by 
> the configure script. So there is something wrong going there, I will 
> look at it.
> 
>  and gdb 5.x. A
> 
> I've been unlucky with GDB 6.x too, but did not check the latest 
> release; I'm currently using 5.3 when running simulations.
> 
>> note in sim/README about them would be great. Or do you have a fix for
>> those issues scheduled?
> 
> 
> --fwritable-strings should be fixed. I'm not sure if the requirement for 
> GDB 5.x still applies though.
> 
>>
>> Well, once you got this far (i.e. the xenoscope is built and an ancient
>> gdb has been prepared), the next step is to produce a test program. Am I
>> overseeing some example?
> 
> 
> Look into ksrc/skins/{vxworks,psos+}/demos. The Makefile also produces a 
> simulation executable for satch. Then run "xenoscope satch_sim"
> 
>  Fortunately, I had that demo I once produced
> 
>> (last year), but that one was easier to build. I first had to drag in
>> the libs and includes of both the simulator and a regular xenomai
>> installation (I think to remember this once worked without this
>> add-ons). Then I need this additional trick in the simulators include 
>> dir:
>>
>> mkdir asm
>> ln -s <xeno-inst-dir>/include/asm-sim asm/xenomai
>>
>> This maps #include <asm/xenomai/system.h> to the correct "arch".
>> Shouldn't this be created automatically during the simulator
>> installation? Or is something else broken on my box?
>>
> 
> You clearly should not need this trick to compile apps against the 
> simulation environment; the instrumenter (gcic) sets the proper flags. 
> I'm going to rebuild one and let you know.

Confirmed. You don't need this hand-made link.

-- 

Philippe.

Re: [Xenomai-core] Re: get the simulator running...

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 1218 bytes --]

Philippe Gerum wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>  Fortunately, I had that demo I once produced
>>
>>> (last year), but that one was easier to build. I first had to drag in
>>> the libs and includes of both the simulator and a regular xenomai
>>> installation (I think to remember this once worked without this
>>> add-ons). Then I need this additional trick in the simulators include
>>> dir:
>>>
>>> mkdir asm
>>> ln -s <xeno-inst-dir>/include/asm-sim asm/xenomai
>>>
>>> This maps #include <asm/xenomai/system.h> to the correct "arch".
>>> Shouldn't this be created automatically during the simulator
>>> installation? Or is something else broken on my box?
>>>
>>
>> You clearly should not need this trick to compile apps against the
>> simulation environment; the instrumenter (gcic) sets the proper flags.
>> I'm going to rebuild one and let you know.
> 
> Confirmed. You don't need this hand-made link.
> 

Err, "confirmed" means that it works for you without the link and the
extra paths for gcic? The compilation of the simulator runs fine with
latest SVN here, but gcic still does not know any include paths.
Attached is the native skin demo I tried.

Jan

[-- Attachment #1.2: nat-demo.c --]
[-- Type: text/plain, Size: 2543 bytes --]

/*
 * nat-demo.c
 *
 * Simple demonstration for a native-skin application inside the MVM simulator
 * (C) 2005-2006 by Jan Kiszka <jan.kiszka@domain.hid>
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 */

#include <native/task.h>
#include <native/sem.h>

RT_TASK demo_task1;
RT_TASK demo_task2;
RT_SEM sem;

void demo1(void *arg)
{
    RTIME now, previous;

    rt_task_set_periodic(NULL, TM_NOW, 1000000000);
    previous = rt_timer_read();

    while (1) {
        rt_task_wait_period(NULL);
        now = rt_timer_read();

        printk("%s: delay since last invocation:: %ld.%06ld ms\n",
               __FUNCTION__,
               (long)(now - previous) / 1000000,
               (long)(now - previous) % 1000000);
        previous = now;

        rt_sem_v(&sem);
    }
}


void demo2(void *arg)
{
    RTIME now, previous;

    previous = rt_timer_read();

    while (1) {
        rt_sem_p(&sem, TM_INFINITE);
        now = rt_timer_read();

        printk("%s: delay since last invocation:: %ld.%06ld ms\n",
               __FUNCTION__,
               (long)(now - previous) / 1000000,
               (long)(now - previous) % 1000000);
        previous = now;
    }
}


/* Note: simulator requires exactly this function name! */
int __xeno_user_init(void)
{
    rt_task_create(&demo_task1, "kdemo1", 0, 99, 0);
    rt_task_create(&demo_task2, "kdemo2", 0, 98, 0);
    rt_sem_create(&sem, NULL, 0, S_PRIO);

    rt_task_start(&demo_task1, &demo1, NULL);
    rt_task_start(&demo_task2, &demo2, NULL);

    return 0;
}


/* Note: simulator requires exactly this function name! */
void __xeno_user_exit(void)
{
    rt_task_delete(&demo_task1);
    rt_task_delete(&demo_task2);
    rt_sem_delete(&sem);
}

module_init(__xeno_user_init);
module_exit(__xeno_user_exit);

MODULE_LICENSE("GPL");

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] Re: get the simulator running...

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Philippe Gerum wrote:
>>
>>>Jan Kiszka wrote:
>>> Fortunately, I had that demo I once produced
>>>
>>>
>>>>(last year), but that one was easier to build. I first had to drag in
>>>>the libs and includes of both the simulator and a regular xenomai
>>>>installation (I think to remember this once worked without this
>>>>add-ons). Then I need this additional trick in the simulators include
>>>>dir:
>>>>
>>>>mkdir asm
>>>>ln -s <xeno-inst-dir>/include/asm-sim asm/xenomai
>>>>
>>>>This maps #include <asm/xenomai/system.h> to the correct "arch".
>>>>Shouldn't this be created automatically during the simulator
>>>>installation? Or is something else broken on my box?
>>>>
>>>
>>>You clearly should not need this trick to compile apps against the
>>>simulation environment; the instrumenter (gcic) sets the proper flags.
>>>I'm going to rebuild one and let you know.
>>
>>Confirmed. You don't need this hand-made link.
>>
> 
> 
> Err, "confirmed" means that it works for you without the link and the
> extra paths for gcic?

Yes (actually, it has always worked for me this way).

  The compilation of the simulator runs fine with
> latest SVN here, but gcic still does not know any include paths.
> Attached is the native skin demo I tried.

gcic explicitely sets -I<install-dir>/include/asm-sim before invoking 
the gcc toolchain. Try adding --verbose to see what's passed.

> 
> Jan
> 
> 
> ------------------------------------------------------------------------
> 
> /*
>  * nat-demo.c
>  *
>  * Simple demonstration for a native-skin application inside the MVM simulator
>  * (C) 2005-2006 by Jan Kiszka <jan.kiszka@domain.hid>
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License as published by
>  * the Free Software Foundation; either version 2 of the License, or
>  * (at your option) any later version.
>  *
>  * This program is distributed in the hope that it will be useful,
>  * but WITHOUT ANY WARRANTY; without even the implied warranty of
>  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>  * GNU General Public License for more details.
>  *
>  * You should have received a copy of the GNU General Public License
>  * along with this program; if not, write to the Free Software
>  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>  */
> 
> #include <native/task.h>
> #include <native/sem.h>
> 
> RT_TASK demo_task1;
> RT_TASK demo_task2;
> RT_SEM sem;
> 
> void demo1(void *arg)
> {
>     RTIME now, previous;
> 
>     rt_task_set_periodic(NULL, TM_NOW, 1000000000);
>     previous = rt_timer_read();
> 
>     while (1) {
>         rt_task_wait_period(NULL);
>         now = rt_timer_read();
> 
>         printk("%s: delay since last invocation:: %ld.%06ld ms\n",
>                __FUNCTION__,
>                (long)(now - previous) / 1000000,
>                (long)(now - previous) % 1000000);
>         previous = now;
> 
>         rt_sem_v(&sem);
>     }
> }
> 
> 
> void demo2(void *arg)
> {
>     RTIME now, previous;
> 
>     previous = rt_timer_read();
> 
>     while (1) {
>         rt_sem_p(&sem, TM_INFINITE);
>         now = rt_timer_read();
> 
>         printk("%s: delay since last invocation:: %ld.%06ld ms\n",
>                __FUNCTION__,
>                (long)(now - previous) / 1000000,
>                (long)(now - previous) % 1000000);
>         previous = now;
>     }
> }
> 
> 
> /* Note: simulator requires exactly this function name! */
> int __xeno_user_init(void)
> {
>     rt_task_create(&demo_task1, "kdemo1", 0, 99, 0);
>     rt_task_create(&demo_task2, "kdemo2", 0, 98, 0);
>     rt_sem_create(&sem, NULL, 0, S_PRIO);
> 
>     rt_task_start(&demo_task1, &demo1, NULL);
>     rt_task_start(&demo_task2, &demo2, NULL);
> 
>     return 0;
> }
> 
> 
> /* Note: simulator requires exactly this function name! */
> void __xeno_user_exit(void)
> {
>     rt_task_delete(&demo_task1);
>     rt_task_delete(&demo_task2);
>     rt_sem_delete(&sem);
> }
> 
> module_init(__xeno_user_init);
> module_exit(__xeno_user_exit);
> 
> MODULE_LICENSE("GPL");


-- 

Philippe.

Re: [Xenomai-core] Re: get the simulator running...

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2416 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>
>>> Philippe Gerum wrote:
>>>
>>>> Jan Kiszka wrote:
>>>> Fortunately, I had that demo I once produced
>>>>
>>>>
>>>>> (last year), but that one was easier to build. I first had to drag in
>>>>> the libs and includes of both the simulator and a regular xenomai
>>>>> installation (I think to remember this once worked without this
>>>>> add-ons). Then I need this additional trick in the simulators include
>>>>> dir:
>>>>>
>>>>> mkdir asm
>>>>> ln -s <xeno-inst-dir>/include/asm-sim asm/xenomai
>>>>>
>>>>> This maps #include <asm/xenomai/system.h> to the correct "arch".
>>>>> Shouldn't this be created automatically during the simulator
>>>>> installation? Or is something else broken on my box?
>>>>>
>>>>
>>>> You clearly should not need this trick to compile apps against the
>>>> simulation environment; the instrumenter (gcic) sets the proper flags.
>>>> I'm going to rebuild one and let you know.
>>>
>>> Confirmed. You don't need this hand-made link.
>>>
>>
>>
>> Err, "confirmed" means that it works for you without the link and the
>> extra paths for gcic?
> 
> Yes (actually, it has always worked for me this way).
> 
>  The compilation of the simulator runs fine with
>> latest SVN here, but gcic still does not know any include paths.
>> Attached is the native skin demo I tried.
> 
> gcic explicitely sets -I<install-dir>/include/asm-sim before invoking
> the gcc toolchain. Try adding --verbose to see what's passed.
> 

kiszka@domain.hid> ../inst/bin/gcic -c nat-demo.c -o
nat-demo_sim.o --verbose
/usr/src/xeno-sim/inst/libexec/gcic/bin/gcc  -isystem
/usr/src/xeno-sim/inst/libexec/gcic/i686-pc-linux-gnu/include -isystem
/usr/src/xeno-sim/inst/libexec/gcic/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include
-E -B/usr/src/xeno-sim/inst/libexec/gcic/lib/gcc-lib/ -D__GCIC__
-D__XENO_SIM__ -D__XENO__ -I/usr/src/xeno-sim/inst/include/asm-sim
-I/usr/src/xeno-sim/inst/include nat-demo.c > /tmp/ic0@domain.hid
nat-demo.c:22: native/task.h: Datei oder Verzeichnis nicht gefunden
nat-demo.c:23: native/sem.h: Datei oder Verzeichnis nicht gefunden
gcic: failed to preprocess nat-demo.c.

I only see the simulator include paths, no link to the xenomai source
base (here: /usr/src/xenomai) or its installation
(/usr/src/xenomai/inst, but I haven't submitted this anyway).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] Re: get the simulator running...

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Philippe Gerum wrote:
>>>
>>>
>>>>Philippe Gerum wrote:
>>>>
>>>>
>>>>>Jan Kiszka wrote:
>>>>>Fortunately, I had that demo I once produced
>>>>>
>>>>>
>>>>>
>>>>>>(last year), but that one was easier to build. I first had to drag in
>>>>>>the libs and includes of both the simulator and a regular xenomai
>>>>>>installation (I think to remember this once worked without this
>>>>>>add-ons). Then I need this additional trick in the simulators include
>>>>>>dir:
>>>>>>
>>>>>>mkdir asm
>>>>>>ln -s <xeno-inst-dir>/include/asm-sim asm/xenomai
>>>>>>
>>>>>>This maps #include <asm/xenomai/system.h> to the correct "arch".
>>>>>>Shouldn't this be created automatically during the simulator
>>>>>>installation? Or is something else broken on my box?
>>>>>>
>>>>>
>>>>>You clearly should not need this trick to compile apps against the
>>>>>simulation environment; the instrumenter (gcic) sets the proper flags.
>>>>>I'm going to rebuild one and let you know.
>>>>
>>>>Confirmed. You don't need this hand-made link.
>>>>
>>>
>>>
>>>Err, "confirmed" means that it works for you without the link and the
>>>extra paths for gcic?
>>
>>Yes (actually, it has always worked for me this way).
>>
>> The compilation of the simulator runs fine with
>>
>>>latest SVN here, but gcic still does not know any include paths.
>>>Attached is the native skin demo I tried.
>>
>>gcic explicitely sets -I<install-dir>/include/asm-sim before invoking
>>the gcc toolchain. Try adding --verbose to see what's passed.
>>
> 
> 
> kiszka@domain.hid> ../inst/bin/gcic -c nat-demo.c -o
> nat-demo_sim.o --verbose
> /usr/src/xeno-sim/inst/libexec/gcic/bin/gcc  -isystem
> /usr/src/xeno-sim/inst/libexec/gcic/i686-pc-linux-gnu/include -isystem
> /usr/src/xeno-sim/inst/libexec/gcic/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include
> -E -B/usr/src/xeno-sim/inst/libexec/gcic/lib/gcc-lib/ -D__GCIC__
> -D__XENO_SIM__ -D__XENO__
-I/usr/src/xeno-sim/inst/include/asm-sim
(1)
> -I/usr/src/xeno-sim/inst/include
(2)
  nat-demo.c > /tmp/ic0@domain.hid
> nat-demo.c:22: native/task.h: Datei oder Verzeichnis nicht gefunden
> nat-demo.c:23: native/sem.h: Datei oder Verzeichnis nicht gefunden
> gcic: failed to preprocess nat-demo.c.
> 
> I only see the simulator include paths, no link to the xenomai source
> base (here: /usr/src/xenomai) or its installation
> (/usr/src/xenomai/inst, but I haven't submitted this anyway).
>

But you don't need any link to the source base, since you should be able 
to compile simulation stuff against a self-contained install dir. gcic 
makes sure that you can reach the internal headers (1) and the 
definitions for the exported API (2), so that #include 
<some_skin/file.h> works. Normally, you should first build and install 
the regular Xenomai support in user-space, then build and install the 
simulator to the same installation directory. E.g. /usr/xenomai should 
both hold the regular and exported simulation-related files, things have 
been crafted so that there is no namespace conflict.

To sum up:

mkdir buildtree && cd buildtree
/usr/src/xenomai/configure --prefix=/usr/src/xenomai/inst
make install
mkdir sim && cd sim
/usr/src/xenomai/sim/configure --prefix=/usr/src/xenomai/inst
make install

The simulation support is seen as just another architecture Xenomai 
provides, except that it is shipped in a separate tarball 
(xenosim-*.tar) you need to dump to a regular Xenomai source tree 
(xenomai-*.tar) before building it.

-- 

Philippe.

Re: [Xenomai-core] Re: get the simulator running...

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 4098 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> Philippe Gerum wrote:
>>>>
>>>>
>>>>> Philippe Gerum wrote:
>>>>>
>>>>>
>>>>>> Jan Kiszka wrote:
>>>>>> Fortunately, I had that demo I once produced
>>>>>>
>>>>>>
>>>>>>
>>>>>>> (last year), but that one was easier to build. I first had to
>>>>>>> drag in
>>>>>>> the libs and includes of both the simulator and a regular xenomai
>>>>>>> installation (I think to remember this once worked without this
>>>>>>> add-ons). Then I need this additional trick in the simulators
>>>>>>> include
>>>>>>> dir:
>>>>>>>
>>>>>>> mkdir asm
>>>>>>> ln -s <xeno-inst-dir>/include/asm-sim asm/xenomai
>>>>>>>
>>>>>>> This maps #include <asm/xenomai/system.h> to the correct "arch".
>>>>>>> Shouldn't this be created automatically during the simulator
>>>>>>> installation? Or is something else broken on my box?
>>>>>>>
>>>>>>
>>>>>> You clearly should not need this trick to compile apps against the
>>>>>> simulation environment; the instrumenter (gcic) sets the proper
>>>>>> flags.
>>>>>> I'm going to rebuild one and let you know.
>>>>>
>>>>> Confirmed. You don't need this hand-made link.
>>>>>
>>>>
>>>>
>>>> Err, "confirmed" means that it works for you without the link and the
>>>> extra paths for gcic?
>>>
>>> Yes (actually, it has always worked for me this way).
>>>
>>> The compilation of the simulator runs fine with
>>>
>>>> latest SVN here, but gcic still does not know any include paths.
>>>> Attached is the native skin demo I tried.
>>>
>>> gcic explicitely sets -I<install-dir>/include/asm-sim before invoking
>>> the gcc toolchain. Try adding --verbose to see what's passed.
>>>
>>
>>
>> kiszka@domain.hid> ../inst/bin/gcic -c nat-demo.c -o
>> nat-demo_sim.o --verbose
>> /usr/src/xeno-sim/inst/libexec/gcic/bin/gcc  -isystem
>> /usr/src/xeno-sim/inst/libexec/gcic/i686-pc-linux-gnu/include -isystem
>> /usr/src/xeno-sim/inst/libexec/gcic/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/include
>>
>> -E -B/usr/src/xeno-sim/inst/libexec/gcic/lib/gcc-lib/ -D__GCIC__
>> -D__XENO_SIM__ -D__XENO__
> -I/usr/src/xeno-sim/inst/include/asm-sim
> (1)
>> -I/usr/src/xeno-sim/inst/include
> (2)
>  nat-demo.c > /tmp/ic0@domain.hid
>> nat-demo.c:22: native/task.h: Datei oder Verzeichnis nicht gefunden
>> nat-demo.c:23: native/sem.h: Datei oder Verzeichnis nicht gefunden
>> gcic: failed to preprocess nat-demo.c.
>>
>> I only see the simulator include paths, no link to the xenomai source
>> base (here: /usr/src/xenomai) or its installation
>> (/usr/src/xenomai/inst, but I haven't submitted this anyway).
>>
> 
> But you don't need any link to the source base, since you should be able
> to compile simulation stuff against a self-contained install dir. gcic
> makes sure that you can reach the internal headers (1) and the
> definitions for the exported API (2), so that #include
> <some_skin/file.h> works. Normally, you should first build and install
> the regular Xenomai support in user-space, then build and install the
> simulator to the same installation directory. E.g. /usr/xenomai should

Ah, that was the missing piece! Then we should better strike out that
"usually" in sim/README:

# $sim_installdir: Installation directory for the simulator;
# (usually, the same place than used for Xenomai's main system).

At least I interpreted this as on option, not a must.

> both hold the regular and exported simulation-related files, things have
> been crafted so that there is no namespace conflict.
> 
> To sum up:
> 
> mkdir buildtree && cd buildtree
> /usr/src/xenomai/configure --prefix=/usr/src/xenomai/inst
> make install
> mkdir sim && cd sim
> /usr/src/xenomai/sim/configure --prefix=/usr/src/xenomai/inst
> make install
> 
> The simulation support is seen as just another architecture Xenomai
> provides, except that it is shipped in a separate tarball
> (xenosim-*.tar) you need to dump to a regular Xenomai source tree
> (xenomai-*.tar) before building it.
> 

Thanks,
Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[Xenomai-core] Re: get the simulator running...

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe,
> 
> here are some patches and comments on the simulator "quick"-start
> process. I guess the patches are due to latest changes in trunk, and I
> cannot guarantee that they are clean - but the simulator compiles now.
> 

The trunk should be fixed now.

-- 

Philippe.