headers
Perrine Martignoni | 1 Jun 2007 09:17
Picon

Re: Xenomai with µClibc

>__real_sem_init should be defined by wrappers.o in libpthread_rt.so,
>what does nm libpthread_rt.so say ?
 
Here is the result of nm libpthread_rt.so :
 
$ nm libpthread_rt.so
0000202c t $a
00005974 t $a
0000235c t $a
000023fc t $a
00005978 t $a
0000244c t $a
00002030 t $a
00005924 t $a
0000596c t $a
00002034 t $a
00002038 t $a
0000597c t $a
00002454 t $a
000024ec t $a
00002884 t $a
000028d8 t $a
000029b4 t $a
00002a24 t $a
00002b08 t $a
00002c1c t $a
00002c68 t $a
00002cb4 t $a
00002d18 t $a
00002d8c t $a
00002dd0 t $a
00002e34 t $a
00002e84 t $a
00002ef0 t $a
00002f4c t $a
00002fa4 t $a
00003004 t $a
00003058 t $a
000030ac t $a
00003128 t $a
000031ac t $a
000031fc t $a
00003258 t $a
00003324 t $a
000033a8 t $a
000033fc t $a
00003458 t $a
000034b4 t $a
0000350c t $a
00003584 t $a
000035b8 t $a
000035f8 t $a
00003638 t $a
0000367c t $a
000036c0 t $a
00003704 t $a
00003748 t $a
0000378c t $a
000037cc t $a
0000380c t $a
000038c4 t $a
00003984 t $a
000039c0 t $a
00003a00 t $a
00003ac0 t $a
00003b20 t $a
00003b70 t $a
00003bcc t $a
00003c30 t $a
00003cc4 t $a
00003d58 t $a
00003dec t $a
00003e84 t $a
00003ec8 t $a
00003f08 t $a
00003f48 t $a
00003f8c t $a
00003fd0 t $a
00004014 t $a
00004058 t $a
0000409c t $a
000040e0 t $a
00004124 t $a
00004164 t $a
000041a8 t $a
000041f4 t $a
00004234 t $a
00004274 t $a
0000430c t $a
00004360 t $a
000043d8 t $a
00004558 t $a
000045b8 t $a
00004684 t $a
000046e8 t $a
00004738 t $a
000047c0 t $a
0000481c t $a
00004938 t $a
00004a04 t $a
00004b1c t $a
00004ba0 t $a
00004c70 t $a
00004d1c t $a
00004dd0 t $a
00004e84 t $a
00004f38 t $a
00004fe8 t $a
000050d4 t $a
000051b8 t $a
00005298 t $a
00005348 t $a
000053f8 t $a
00005494 t $a
0000554c t $a
000055d0 t $a
000056c0 t $a
0000575c t $a
000057f8 t $a
00005908 t $a
000058f0 t __aeabi_uidivmod
0000ddf0 A __bss_end__
0000ddf0 A _bss_end__
0000dde4 A __bss_start
0000dde4 A __bss_start__
0000596c t call___do_global_ctors_aux
000023fc t call___do_global_dtors_aux
0000244c t call_frame_dummy
         U close
0000dde4 b completed.3705
0000dba8 d __CTOR_END__
0000dba0 d __CTOR_LIST__
         w __cxa_finalize
0000dba0 d $d
0000dbac d $d
0000ddcc d $d
0000ddd0 d $d
000023e8 t $d
00002440 t $d
00005964 t $d
0000ddd4 d $d
000024dc t $d
00002828 t $d
0000dba4 d $d
000028c8 t $d
000029a0 t $d
00002a18 t $d
00002af4 t $d
00002c14 t $d
00002c5c t $d
00002cac t $d
00002d0c t $d
00002d7c t $d
00002dc4 t $d
00002e28 t $d
00002e7c t $d
00002ee4 t $d
00002f40 t $d
00002f98 t $d
00002ffc t $d
0000304c t $d
000030a0 t $d
0000311c t $d
000031a0 t $d
000031f4 t $d
0000324c t $d
0000331c t $d
0000339c t $d
000033f0 t $d
0000344c t $d
000034a8 t $d
00003504 t $d
00003578 t $d
000035ec t $d
0000362c t $d
00003670 t $d
000036b8 t $d
000036f8 t $d
0000373c t $d
00003784 t $d
000037c0 t $d
00003800 t $d
000038b4 t $d
00003974 t $d
000039b8 t $d
000039f4 t $d
00003ab0 t $d
00003b14 t $d
00003b68 t $d
00003bc0 t $d
00003c24 t $d
00003cb8 t $d
00003d50 t $d
00003de0 t $d
00003e78 t $d
00003ec0 t $d
00003efc t $d
00003f3c t $d
00003f80 t $d
00003fc8 t $d
00004008 t $d
0000404c t $d
00004090 t $d
000040d8 t $d
00004118 t $d
00004158 t $d
000041a0 t $d
000041e8 t $d
00004228 t $d
00004268 t $d
000042fc t $d
00004354 t $d
000043d0 t $d
00004548 t $d
000045ac t $d
00004678 t $d
000046dc t $d
00004730 t $d
000047b4 t $d
00004810 t $d
00004924 t $d
000049f4 t $d
00004b0c t $d
00004b90 t $d
00004c60 t $d
00004d10 t $d
00004dc0 t $d
00004e74 t $d
00004f28 t $d
00004fdc t $d
000050c8 t $d
000051a8 t $d
0000528c t $d
00005338 t $d
000053e8 t $d
00005484 t $d
0000553c t $d
000055c0 t $d
000056b0 t $d
0000574c t $d
000057e8 t $d
0000ddcc D __data_start
00005908 t __div0
00005924 t __do_global_ctors_aux
0000235c t __do_global_dtors_aux
0000ddcc d __dso_handle
0000dbb0 d __DTOR_END__
0000dbac d __DTOR_LIST__
0000dbb8 A _DYNAMIC
0000dde4 A _edata
0000ddf0 A _end
0000ddf0 A __end__
         U __errno_location
         U exit
         U fflush
00005974 T _fini
0000dde8 b fork_handler_registered
         U fprintf
00002404 t frame_dummy
00005b9c r __FRAME_END__
         U free
         U fwrite
0000dc70 a _GLOBAL_OFFSET_TABLE_
0000202c T _init
000024ec t __init_posix_interface
0000dbb4 d __JCR_END__
0000dbb4 d __JCR_LIST__
         w _Jv_RegisterClasses
         U malloc
         U mlockall
         U mprotect
         U munlockall
0000ddec b old_sigharden_handler
0000ddd0 d p.3704
         U perror
0000dddc D __pse51_muxid
         U pthread_atfork
         U pthread_attr_getinheritsched
         U pthread_attr_getschedparam
         U pthread_attr_getschedpolicy
         U _pthread_cleanup_pop
         U _pthread_cleanup_push
000037cc t __pthread_cond_cleanup
         U pthread_exit
00004684 T pthread_intr_attach_np
000047c0 T pthread_intr_control_np
000046e8 T pthread_intr_detach_np
00004738 T pthread_intr_wait_np
         U pthread_kill
00002c6c T pthread_make_periodic_np
         U pthread_self
         U pthread_setcanceltype
00002d18 T pthread_set_mode_np
00002d8c T pthread_set_name_np
00002884 t __pthread_sigharden_handler
         U pthread_testcancel
00002a24 t __pthread_trampoline
00002cb4 T pthread_wait_np
         U __real_accept
         U __real_bind
         U __real_close
         U __real_connect
         U __real_ftruncate
         U __real_getpeername
         U __real_getsockname
         U __real_getsockopt
         U __real_ioctl
         U __real_listen
         U __real_mmap
         U __real_munmap
         U __real_open
         U __real_pthread_create
         U __real_pthread_getschedparam
         U __real_pthread_setschedparam
         U __real_read
         U __real_recv
         U __real_recvfrom
         U __real_recvmsg
         U __real_sched_yield
         U __real_sem_destroy
         U __real_sem_init
         U __real_sem_post
         U __real_sem_wait
         U __real_send
         U __real_sendmsg
         U __real_sendto
         U __real_setsockopt
         U __real_shutdown
         U __real_socket
         U __real_write
0000ddd4 D __rtdm_fd_start
0000ddd8 D __rtdm_muxid
00004558 T __shm_close
         U sigaction
         U sigemptyset
         U signal
         U stderr
         U strerror
         U strncmp
000057f8 t __udivsi3
000055d0 T __wrap_accept
000053f8 T __wrap_bind
000033fc T __wrap_clock_getres
00003458 T __wrap_clock_gettime
0000350c T __wrap_clock_nanosleep
000034b4 T __wrap_clock_settime
00004ba0 T __wrap_close
00005494 T __wrap_connect
00004360 T __wrap_ftruncate
0000575c T __wrap_getpeername
000056c0 T __wrap_getsockname
00005298 T __wrap_getsockopt
00004c70 T __wrap_ioctl
0000554c T __wrap_listen
000043d8 T __wrap_mmap
00003ac0 T __wrap_mq_close
00003b70 T __wrap_mq_getattr
00003e84 T __wrap_mq_notify
00003a00 T __wrap_mq_open
00003d58 T __wrap_mq_receive
00003c30 T __wrap_mq_send
00003bcc T __wrap_mq_setattr
00003dec T __wrap_mq_timedreceive
00003cc4 T __wrap_mq_timedsend
00003b20 T __wrap_mq_unlink
000045b8 T __wrap_munmap
00003584 T __wrap_nanosleep
0000481c T __wrap_open
000035f8 T __wrap_pthread_condattr_destroy
00003638 T __wrap_pthread_condattr_getclock
000036c0 T __wrap_pthread_condattr_getpshared
000035b8 T __wrap_pthread_condattr_init
0000367c T __wrap_pthread_condattr_setclock
00003704 T __wrap_pthread_condattr_setpshared
000039c0 T __wrap_pthread_cond_broadcast
0000378c T __wrap_pthread_cond_destroy
00003748 T __wrap_pthread_cond_init
00003984 T __wrap_pthread_cond_signal
000038c4 T __wrap_pthread_cond_timedwait
0000380c T __wrap_pthread_cond_wait
00002b08 T __wrap_pthread_create
000029b4 T __wrap_pthread_getschedparam
00003f08 T __wrap_pthread_mutexattr_destroy
00003fd0 T __wrap_pthread_mutexattr_getprotocol
00004058 T __wrap_pthread_mutexattr_getpshared
00003f48 T __wrap_pthread_mutexattr_gettype
00003ec8 T __wrap_pthread_mutexattr_init
00004014 T __wrap_pthread_mutexattr_setprotocol
0000409c T __wrap_pthread_mutexattr_setpshared
00003f8c T __wrap_pthread_mutexattr_settype
00004124 T __wrap_pthread_mutex_destroy
000040e0 T __wrap_pthread_mutex_init
00004164 T __wrap_pthread_mutex_lock
000041a8 T __wrap_pthread_mutex_timedlock
000041f4 T __wrap_pthread_mutex_trylock
00004234 T __wrap_pthread_mutex_unlock
000028d8 T __wrap_pthread_setschedparam
00002c68 T __wrap_pthread_yield
00004d1c T __wrap_read
000050d4 T __wrap_recv
00004a04 T __wrap_recvfrom
00004e84 T __wrap_recvmsg
00002c1c T __wrap_sched_yield
00003324 T __wrap_sem_close
00003004 T __wrap_sem_destroy
000031fc T __wrap_sem_getvalue
00002fa4 T __wrap_sem_init
00003258 T __wrap_sem_open
00003058 T __wrap_sem_post
00003128 T __wrap_sem_timedwait
000031ac T __wrap_sem_trywait
000033a8 T __wrap_sem_unlink
000030ac T __wrap_sem_wait
000051b8 T __wrap_send
00004f38 T __wrap_sendmsg
00004fe8 T __wrap_sendto
00005348 T __wrap_setsockopt
00004274 T __wrap_shm_open
0000430c T __wrap_shm_unlink
00004b1c T __wrap_shutdown
00004938 T __wrap_socket
00002dd0 T __wrap_timer_create
00002e34 T __wrap_timer_delete
00002f4c T __wrap_timer_getoverrun
00002ef0 T __wrap_timer_gettime
00002e84 T __wrap_timer_settime
00004dd0 T __wrap_write
00002454 t xeno_handle_mlock_alert
0000dde0 V xeno_sigxcpu_no_mlock

 
On 5/31/07, Gilles Chanteperdrix <gilles.chanteperdrix <at> laposte.net> wrote:
Perrine Martignoni wrote:
> I tried to put essai_mutex.c before the flags but it's the same thing.
>
> It compiles with no problem, and after when I want to launch it on my
> board I have the error about __real_sem_init.
>
> I noticed that with cyclictest it's the same. When I want to launch the
> application, I have the same error :
> can't resolve symbol '__real_sem_init'

__real_sem_init should be defined by wrappers.o in libpthread_rt.so,
what does nm libpthread_rt.so say ?

--
                                                Gilles Chanteperdrix

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Permalink | Reply | 1 comment |
headers
Gilles Chanteperdrix | 1 Jun 2007 09:30
Favicon

Re: Xenomai with µClibc

Perrine Martignoni wrote:
 > >__real_sem_init should be defined by wrappers.o in libpthread_rt.so,
 > >what does nm libpthread_rt.so say ?
 > 
 > Here is the result of nm libpthread_rt.so :
 > 
 >          U __real_accept
 >          U __real_bind
 >          U __real_close
 >          U __real_connect
 >          U __real_ftruncate
 >          U __real_getpeername
 >          U __real_getsockname
 >          U __real_getsockopt
 >          U __real_ioctl
 >          U __real_listen
 >          U __real_mmap
 >          U __real_munmap
 >          U __real_open
 >          U __real_pthread_create
 >          U __real_pthread_getschedparam
 >          U __real_pthread_setschedparam
 >          U __real_read
 >          U __real_recv
 >          U __real_recvfrom
 >          U __real_recvmsg
 >          U __real_sched_yield
 >          U __real_sem_destroy
 >          U __real_sem_init
 >          U __real_sem_post
 >          U __real_sem_wait
 >          U __real_send
 >          U __real_sendmsg
 >          U __real_sendto
 >          U __real_setsockopt
 >          U __real_shutdown
 >          U __real_socket
 >          U __real_write

Looks like wrappers.c is missing. Could you show us the command line
used when xenomai builds libpthread_rt.so ?

--

-- 

					    Gilles Chanteperdrix.
Permalink | Reply | 0 comments |
headers
Wolfgang Grandegger | 1 Jun 2007 10:26

Re: Xenomai with µClibc

Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Jan Kiszka wrote:
>>> Perrine Martignoni wrote:
>>>>> Perrine, did you happen to configure Xenomai with "configure --host=arm
>>>>> ..."? If yes (see config.log), please use "--host=arm-linux". This
>>>>> solved all issues for me.
>>>>>
>>>>> Awaiting your feedback!
>>>> I configure Xenomai with --host=arm.
>>>> I tried to configure like this but it doesn't work :
>>>>
>>>> ./configure --build=arm-linux --host=arm-linux CC=arm-linux-gcc
>>>                       ^^^^^^^^^
>>> I guess you are not compiling Xenomai _on_ an ARM box, are you? :)
>>> Try --build=i686-linux here.
>> Or just omit it. Also CC=, CXX=, LD= ist not necessary. For PowerPC with 
>> the ELDK, I just use
>>
>>   ./configure --host=ppc-linux
>>
>> to configure Xenomai.
> 
> Can we define a common ground for this in README.INSTALL, for all archs?
> The simpler, the better.
> 
> I was heavily misled by the PPC section, because I do not cross-compile
> everyday, thus had to look up the procedure again and managed to pick
> the bad example...

I had a closer look and realized, that passing just CC, CXX and LD to 
the configure script is not enough. There should at least also AR and 
RANLIB, otherwise the corresponding host tools are used. Then I think, 
it should be equivalent to automatic tool assignment via --host.

Also note, that "--host=arm" will also work with the ELDK, because there 
are links arm-* to the tools arm-linux-*. I Perrine's configure examples 
above, arm-ar and arm-ranlib will then be used.

FYI, I have also asked the authors of the ELDK to have a closer look to 
the mentioned build problems with the uClibc versions of the ELDK.

Wolfgang.
Permalink | Reply | 6 comments |
headers
RAKOTOSALAMA, Nirilanto | 1 Jun 2007 10:36
Favicon

Re: [Newbie question] threads and task CPU affinity

> > > Hi,
> > > 
> > > I'm still blocked on a CPU affinity problem.
> > > In order to adapt a set affinity function which is based on
> > > posix linux lib :
> > > - CPU_AssignPID(uint32 PID, uint32 CPU_id)
> > > - the cpu affinity of the caller and all its child threads 
> > must be set to CPU_id.
> > > 
> > > Problems are:
> > > Child PIDs must be listed, the only means I found is 
> > listing pids using `ls /proc/"Parent pid"/ > temp_file`
> > > And each listed pid is sched_setaffinity'ed.
> > > I don't know if setting affinity of RT threads from an 
> > other thread (parent) using pid works with xenomai.
> > > 
> > > So, my question is :
> > > With xenomai, is recursively cpu affinity setting from a 
> > parent thread, a good way of doing ?
> > > I read switchtest program, and I conclude that in a xenomai 
> > and RT perspective, it seems "nicer"
> > > to set affinity each threads separately during their init 
> > phase before the RT infinite loop.
> > > Otherwise, setting affinity after child threads creation 
> > from its parent, may switch them into 
> > > secondary mode during their RT loop, and at an unknown moment.
> > > Argumentation is important for my internship because I have 
> > to port on xenomai a very big RT 
> > > posix based application. And I should justify any 
> > modifications and prevent potential problems.
> > > 
> > > Sorry, I don't know if it is clear.
> > 
> > I think that it is safe to assume that if the affinity of a 
> thread is
> > inherited from the thread that created it with Linux posix 
> > library, the
> > same will happen with Xenomai.
> > 
> > Now, if you want to set the affinity of a group of threads 
> after their
> > creation, I do not see how to do this without walking 
> through the list
> > of threads. If your library has an abstraction for threads, 
> > you can keep
> > them in a list. It will be useful at process exit time to 
> > cleanly cancel
> > all threads (this may be useful if you want to detect leaks 
> > for instance).
> > 
> > Note that when talking about scheduling affinity function, we are
> > swimming in the undefined, since these functions are not 
> > standardized by
> > posix.
> > 
> > But since you are porting a library to Xenomai maybe you can 
> > have a look
> > at the current implementation of CPU_AssignPID ?
> > 
> > -- 
> >                                                  Gilles Chanteperdrix
> 
> Thanks,
> Precisly, the current implementation has nothing curious and 
> there is no reason it does not work on xenomai but,
> in a simple program that just switches the cpu :
> Before CPU_assignpid call, 'ps -ax -0 SCHED | grep <pid>'
> and '/proc/xenomai/sched' returns the same result (i.e. the 
> current thread runs on the same cpu)
> After CPU_assignpid call, 'ps -ax -0 SCHED | grep <pid>' 
> shows that threads cpu has switched
> whereas '/proc/xenomai/sched' shows no changes.
> 
> Does '/proc/xenomai/sched' not change during running, if yes
> I continue debugging my program ?

Hi,

I run with gdb a test program that only create a 1 sec periodic thread that 
rt_timer_spin's during 10ms and waits. 
As above-written, when cpu is assigned _after_ child thread creation,
'ps -ax -0 SCHED | grep <pid>' shows a cpu switch on main thread whereas,
'/proc/xenomai/sched' doesn't.
When cpu is assigned _before_ child thread creation,
'ps -ax -0 SCHED | grep <pid>' shows a cpu switch on main thread,
and '/proc/xenomai/sched' shows no changes for main thread but
the child thread cpu is the assigned one.

Is it right to supposed that, cpu switching is effective according to
'ps -ax -0 SCHED | grep <pid>' even in xenomai context ?
Does '/proc/xenomai/sched' not change during running ?
In this case, how can children threads cpu status be read dynamically like
'ps -ax -0 SCHED | grep <pid>' command for main thread ?

Thanks.
Niry

This e-mail is intended only for the above addressee. It may contain privileged information.
If you are not the addressee you must not copy, distribute, disclose or use any of the information in it. 
If you have received it in error please delete it and immediately notify the sender.
Security Notice: all e-mail, sent to or from this address, may be accessed by someone other than the
recipient, for system management and security reasons. This access is controlled under Regulation of
security reasons.
This access is controlled under Regulation of Investigatory Powers Act 2000, Lawful Business Practises.
Permalink | Reply | 15 comments |
headers
Jan Kiszka | 1 Jun 2007 10:48
Picon

Re: Xenomai with µClibc

Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Jan Kiszka wrote:
>>>> Perrine Martignoni wrote:
>>>>>> Perrine, did you happen to configure Xenomai with "configure
>>>>>> --host=arm
>>>>>> ..."? If yes (see config.log), please use "--host=arm-linux". This
>>>>>> solved all issues for me.
>>>>>>
>>>>>> Awaiting your feedback!
>>>>> I configure Xenomai with --host=arm.
>>>>> I tried to configure like this but it doesn't work :
>>>>>
>>>>> ./configure --build=arm-linux --host=arm-linux CC=arm-linux-gcc
>>>>                       ^^^^^^^^^
>>>> I guess you are not compiling Xenomai _on_ an ARM box, are you? :)
>>>> Try --build=i686-linux here.
>>> Or just omit it. Also CC=, CXX=, LD= ist not necessary. For PowerPC
>>> with the ELDK, I just use
>>>
>>>   ./configure --host=ppc-linux
>>>
>>> to configure Xenomai.
>>
>> Can we define a common ground for this in README.INSTALL, for all archs?
>> The simpler, the better.
>>
>> I was heavily misled by the PPC section, because I do not cross-compile
>> everyday, thus had to look up the procedure again and managed to pick
>> the bad example...
> 
> I had a closer look and realized, that passing just CC, CXX and LD to
> the configure script is not enough. There should at least also AR and
> RANLIB, otherwise the corresponding host tools are used. Then I think,
> it should be equivalent to automatic tool assignment via --host.
> 
> Also note, that "--host=arm" will also work with the ELDK, because there
> are links arm-* to the tools arm-linux-*. I Perrine's configure examples
> above, arm-ar and arm-ranlib will then be used.

But the issue is that in this case configure is unable to find the
target OS and fails to detect that shared libs are supported for the
target. Non-shared build fails with ELDK for unknown reasons.

Jan


_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Permalink | Reply | 5 comments |
headers
Wolfgang Grandegger | 1 Jun 2007 11:09

Re: Xenomai with µClibc

Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Jan Kiszka wrote:
>>> Wolfgang Grandegger wrote:
>>>> Jan Kiszka wrote:
>>>>> Perrine Martignoni wrote:
>>>>>>> Perrine, did you happen to configure Xenomai with "configure
>>>>>>> --host=arm
>>>>>>> ..."? If yes (see config.log), please use "--host=arm-linux". This
>>>>>>> solved all issues for me.
>>>>>>>
>>>>>>> Awaiting your feedback!
>>>>>> I configure Xenomai with --host=arm.
>>>>>> I tried to configure like this but it doesn't work :
>>>>>>
>>>>>> ./configure --build=arm-linux --host=arm-linux CC=arm-linux-gcc
>>>>>                       ^^^^^^^^^
>>>>> I guess you are not compiling Xenomai _on_ an ARM box, are you? :)
>>>>> Try --build=i686-linux here.
>>>> Or just omit it. Also CC=, CXX=, LD= ist not necessary. For PowerPC
>>>> with the ELDK, I just use
>>>>
>>>>   ./configure --host=ppc-linux
>>>>
>>>> to configure Xenomai.
>>> Can we define a common ground for this in README.INSTALL, for all archs?
>>> The simpler, the better.
>>>
>>> I was heavily misled by the PPC section, because I do not cross-compile
>>> everyday, thus had to look up the procedure again and managed to pick
>>> the bad example...
>> I had a closer look and realized, that passing just CC, CXX and LD to
>> the configure script is not enough. There should at least also AR and
>> RANLIB, otherwise the corresponding host tools are used. Then I think,
>> it should be equivalent to automatic tool assignment via --host.
>>
>> Also note, that "--host=arm" will also work with the ELDK, because there
>> are links arm-* to the tools arm-linux-*. I Perrine's configure examples
>> above, arm-ar and arm-ranlib will then be used.
> 
> But the issue is that in this case configure is unable to find the
> target OS and fails to detect that shared libs are supported for the
> target. Non-shared build fails with ELDK for unknown reasons.

Why it is unable to find the target OS. Can you provide an example? And 
non-shared builds only fail with the ARM uClibc toolchain from the ELDK. 
It builds fine with the normal ARM tool-chain.

Wolfgang.
Permalink | Reply | 4 comments |
headers
Gilles Chanteperdrix | 1 Jun 2007 11:07
Favicon

Problem trying to find secondary mode switches.


Hi,

I am using the XNTRAPSW option to try and find secondary mode switches
in some piece of code for which I do not have the sources. I have
installed the usual signal handler which dumps the backtrace, just as in
ksrc/skins/native/snippet/sigxcpu.c. But the problem is that the
backtrace is not helpful, it show addresses in libpthread and
libpthread_rt global destructor sections.

By adding some printks in shadow.c I know that what causes the mode
switch is the linux arm syscall 78 aka gettimeofday.

So, my question is: is there any chance that the signal sent by send_sig
in xnshadow_relax could be received by another thread than send_sig
target ? If not, where should I look for the reason of this wrong
backtrace ?

--

-- 
                                                 Gilles Chanteperdrix
Permalink | Reply | 1 comment |
headers
Jan Kiszka | 1 Jun 2007 11:11
Picon

Re: Xenomai with µClibc

Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>> Jan Kiszka wrote:
>>>> Wolfgang Grandegger wrote:
>>>>> Jan Kiszka wrote:
>>>>>> Perrine Martignoni wrote:
>>>>>>>> Perrine, did you happen to configure Xenomai with "configure
>>>>>>>> --host=arm
>>>>>>>> ..."? If yes (see config.log), please use "--host=arm-linux". This
>>>>>>>> solved all issues for me.
>>>>>>>>
>>>>>>>> Awaiting your feedback!
>>>>>>> I configure Xenomai with --host=arm.
>>>>>>> I tried to configure like this but it doesn't work :
>>>>>>>
>>>>>>> ./configure --build=arm-linux --host=arm-linux CC=arm-linux-gcc
>>>>>>                       ^^^^^^^^^
>>>>>> I guess you are not compiling Xenomai _on_ an ARM box, are you? :)
>>>>>> Try --build=i686-linux here.
>>>>> Or just omit it. Also CC=, CXX=, LD= ist not necessary. For PowerPC
>>>>> with the ELDK, I just use
>>>>>
>>>>>   ./configure --host=ppc-linux
>>>>>
>>>>> to configure Xenomai.
>>>> Can we define a common ground for this in README.INSTALL, for all
>>>> archs?
>>>> The simpler, the better.
>>>>
>>>> I was heavily misled by the PPC section, because I do not cross-compile
>>>> everyday, thus had to look up the procedure again and managed to pick
>>>> the bad example...
>>> I had a closer look and realized, that passing just CC, CXX and LD to
>>> the configure script is not enough. There should at least also AR and
>>> RANLIB, otherwise the corresponding host tools are used. Then I think,
>>> it should be equivalent to automatic tool assignment via --host.
>>>
>>> Also note, that "--host=arm" will also work with the ELDK, because there
>>> are links arm-* to the tools arm-linux-*. I Perrine's configure examples
>>> above, arm-ar and arm-ranlib will then be used.
>>
>> But the issue is that in this case configure is unable to find the
>> target OS and fails to detect that shared libs are supported for the
>> target. Non-shared build fails with ELDK for unknown reasons.
> 
> Why it is unable to find the target OS. Can you provide an example? And

Look at the configure script. :o) [This is how I found the reason for
the non-shared build.]

> non-shared builds only fail with the ARM uClibc toolchain from the ELDK.
> It builds fine with the normal ARM tool-chain.

OK, good to know that the issue is confined.

Jan


_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Permalink | Reply | 2 comments |
headers
Perrine Martignoni | 1 Jun 2007 11:11
Picon

Re: Xenomai with µClibc

>Looks like wrappers.c is missing. Could you show us the command line
>used when xenomai builds libpthread_rt.so ?
 
Yes. it's because of wrappers.c.
It's my fault. I did an experiment.

Now, it works fine.
 
Thanks a lot
 
On 6/1/07, Wolfgang Grandegger <wg <at> grandegger.com> wrote:
Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Jan Kiszka wrote:
>>> Wolfgang Grandegger wrote:
>>>> Jan Kiszka wrote:
>>>>> Perrine Martignoni wrote:
>>>>>>> Perrine, did you happen to configure Xenomai with "configure
>>>>>>> --host=arm
>>>>>>> ..."? If yes (see config.log), please use "--host=arm-linux". This
>>>>>>> solved all issues for me.
>>>>>>>
>>>>>>> Awaiting your feedback!
>>>>>> I configure Xenomai with --host=arm.
>>>>>> I tried to configure like this but it doesn't work :
>>>>>>
>>>>>> ./configure --build=arm-linux --host=arm-linux CC=arm-linux-gcc
>>>>>                       ^^^^^^^^^
>>>>> I guess you are not compiling Xenomai _on_ an ARM box, are you? :)
>>>>> Try --build=i686-linux here.
>>>> Or just omit it. Also CC=, CXX=, LD= ist not necessary. For PowerPC
>>>> with the ELDK, I just use
>>>>
>>>>   ./configure --host=ppc-linux
>>>>
>>>> to configure Xenomai.
>>> Can we define a common ground for this in README.INSTALL, for all archs?
>>> The simpler, the better.
>>>
>>> I was heavily misled by the PPC section, because I do not cross-compile
>>> everyday, thus had to look up the procedure again and managed to pick
>>> the bad example...
>> I had a closer look and realized, that passing just CC, CXX and LD to
>> the configure script is not enough. There should at least also AR and
>> RANLIB, otherwise the corresponding host tools are used. Then I think,
>> it should be equivalent to automatic tool assignment via --host.
>>
>> Also note, that "--host=arm" will also work with the ELDK, because there
>> are links arm-* to the tools arm-linux-*. I Perrine's configure examples
>> above, arm-ar and arm-ranlib will then be used.
>
> But the issue is that in this case configure is unable to find the
> target OS and fails to detect that shared libs are supported for the
> target. Non-shared build fails with ELDK for unknown reasons.

Why it is unable to find the target OS. Can you provide an example? And
non-shared builds only fail with the ARM uClibc toolchain from the ELDK.
It builds fine with the normal ARM tool-chain.

Wolfgang.


_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help

_______________________________________________
Xenomai-help mailing list
Xenomai-help <at> gna.org
https://mail.gna.org/listinfo/xenomai-help
Permalink | Reply | 0 comments |
headers
Dmitry Adamushko | 1 Jun 2007 11:43
Picon

Re: Problem trying to find secondary mode switches.

Hi,

> [...]
> So, my question is: is there any chance that the signal sent by send_sig
> in xnshadow_relax could be received by another thread than send_sig
> target ?

Nop, as far as I can see. Anyway, you can easily verify it by printing
current->pid for the send_sig()'s target in xnshadow_relax() and
calling gettid() (not getpid()) in your signal handler.

> If not, where should I look for the reason of this wrong
> backtrace ?

Are you sure backtrace() is always workable on ARM? I just know that
it's not a case for MIPS..

>
> --
>                                                  Gilles Chanteperdrix

--

-- 
Best regards,
Dmitry Adamushko
Permalink | Reply | 0 comments |

Gmane