Re: [Xenomai] xenomai-2.6.0 instrumentation commands not executing

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 06/06/2012 03:25 PM, Philippe Gerum wrote:
> On 06/06/2012 03:18 PM, Gilles Chanteperdrix wrote:
>> On 06/06/2012 02:28 PM, Philippe Gerum wrote:
>>> On 06/06/2012 11:48 AM, Philippe Gerum wrote:
>>>> On 06/06/2012 11:18 AM, ali hagigat wrote:
>>>>> Much appreciate for the reply, Mr. Gerum. Here is the result of ldd
>>>>> command:
>>>>>
>>>>
>>>> http://www.xenomai.org/pipermail/xenomai-help/2011-12/msg00012.html
>>>
>>> Alternatively, this patch may work as well (not tested, but this
>>> looks like a former issue we had with aggressive optimizers):
>>>
>>> diff --git a/src/skins/posix/init.c b/src/skins/posix/init.c
>>> index 7a338a0..9c7849e 100644
>>> --- a/src/skins/posix/init.c
>>> +++ b/src/skins/posix/init.c
>>> @@ -43,6 +43,7 @@ void pse51_clock_init(int);
>>>   static __attribute__ ((constructor))
>>>   void __init_posix_interface(void)
>>>   {
>>> +	volatile pthread_t tid = pthread_self();
>>>   #ifndef CONFIG_XENO_LIBS_DLOPEN
>>>   	struct sched_param parm;
>>>   	int policy;
>>> @@ -80,14 +81,14 @@ void __init_posix_interface(void)
>>>
>>>   	/* Don't use auto-shadowing if we are likely invoked from dlopen. */
>>>   #ifndef CONFIG_XENO_LIBS_DLOPEN
>>> -	err = __real_pthread_getschedparam(pthread_self(),&policy,&parm);
>>> +	err = __real_pthread_getschedparam(tid,&policy,&parm);
>>>   	if (err) {
>>>   		fprintf(stderr, "Xenomai Posix skin init: "
>>>   			"pthread_getschedparam: %s\n", strerror(err));
>>>   		exit(EXIT_FAILURE);
>>>   	}
>>>
>>> -	err = __wrap_pthread_setschedparam(pthread_self(), policy,&parm);
>>> +	err = __wrap_pthread_setschedparam(tid, policy,&parm);
>>>   	if (err) {
>>>   		fprintf(stderr, "Xenomai Posix skin init: "
>>>   			"pthread_setschedparam: %s\n", strerror(err));
>>
>> There should not be any issue here, as the pthread_self() is passed as
>> an argument to the called functions, the syscall is not inlined directly.
>>
> 
> Did you get any disassembly of the faulty code when suggesting 
> -fno-omit-frame-pointer last time you did?
> 
No, but I had experienced the problem first hand.

-- 
					    Gilles.