Project Home
Project Home		 Source Code
Source Code		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Core Development Tools/Discussion/General/problem with -finstrument-functions and qcc 4.2.4 on ARM/List of Posts
Forum Topic - problem with -finstrument-functions and qcc 4.2.4 on ARM: (12 Items)
   
Update
Hans-Peter Reichert
08/27/2009 3:19 PM
post36822
problem with -finstrument-functions and qcc 4.2.4 on ARM   
I've a shared object that is build using -finsturment-functions
source looks like this:
   void get_my_addr()   __attribute__((no_instrument_function));
   void __cyg_profile_func_enter (void *this_fn, void *call_site)   __attribute__((no_instrument_function));
   void __cyg_profile_func_exit  (void *this_fn,  void *call_site)  __attribute__((no_instrument_function));

   unsigned get_my_addr() {
      return __builtin_return_address(0);
   }
   void foo()    {
      TraceEvent( _NTO_TRACE_INSERTSUSEREVENT, 254, 0, 0);
      TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, 5, _NTO_TRACE_SYS_FUNC_ENTER, (unsigned)get_my_addr(), 
(unsigned)__builtin_return_address(0) );
      TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, 5, _NTO_TRACE_SYS_FUNC_ENTER, (unsigned)foo, 
(unsigned)__builtin_return_address(0) );
   }

I am satisfying the __cyg_profile_func_enter/exit functions on my own using this implementation:
   void __cyg_profile_func_enter (void *this_fn, void *call_site) {
      TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, 5, _NTO_TRACE_SYS_FUNC_ENTER, (unsigned)this_fn, (unsigned)call_site );
   }
   void __cyg_profile_func_exit  (void *this_fn,  void *call_site) {
      TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, 5, _NTO_TRACE_SYS_FUNC_EXIT, (unsigned)this_fn, (unsigned)call_site );
   }

So now let us look at the results from a k-trace:

197147, 5s 561us, (393236) (7), Function Enter, function_addr 0x1041a4 call_site 0x15c8e4
197148, 5s 575us, (393236) (7), User Event 254, string  d0 0 d1 0
197151, 5s 613us, (393236) (7), Function Enter, function_addr 0x1076adc call_site 0x15c8e4
197152, 5s 625us, (393236) (7), Function Enter, function_addr 0x1041a4 call_site 0x15c8e4

Line 1 is from compiler generated call to __cyg_profile_func_enter
Line 2 is the user TraceEvent 254 you see in the source
Line 3 is the self made enter event using a call to get_my_addr()
Line 4 is the self inserted event using the f-ptr

Looking at "function_addr" you see different values,
the problem is that the reported addresses are wrong expect the one that i get by calling get_my_addr()
The load address of the shared object from pidin mem is 0x1075000
you see the reported addresses do not match the load address.

any suggestions?
hp
Colin Burgess(deleted)
08/27/2009 3:35 PM
post36823
Re: problem with -finstrument-functions and qcc 4.2.4 on ARM   
Look like it's reporting the address in the plt

Hans-Peter Reichert wrote:
> I've a shared object that is build using -finsturment-functions
> source looks like this:
>    void get_my_addr()   __attribute__((no_instrument_function));
>    void __cyg_profile_func_enter (void *this_fn, void *call_site)   __attribute__((no_instrument_function));
>    void __cyg_profile_func_exit  (void *this_fn,  void *call_site)  __attribute__((no_instrument_function));
> 
>    unsigned get_my_addr() {
>       return __builtin_return_address(0);
>    }
>    void foo()    {
>       TraceEvent( _NTO_TRACE_INSERTSUSEREVENT, 254, 0, 0);
>       TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, 5, _NTO_TRACE_SYS_FUNC_ENTER, (unsigned)get_my_addr(), 
(unsigned)__builtin_return_address(0) );
>       TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, 5, _NTO_TRACE_SYS_FUNC_ENTER, (unsigned)foo, 
(unsigned)__builtin_return_address(0) );
>    }
> 
> I am satisfying the __cyg_profile_func_enter/exit functions on my own using this implementation:
>    void __cyg_profile_func_enter (void *this_fn, void *call_site) {
>       TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, 5, _NTO_TRACE_SYS_FUNC_ENTER, (unsigned)this_fn, (unsigned)call_site )
;
>    }
>    void __cyg_profile_func_exit  (void *this_fn,  void *call_site) {
>       TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, 5, _NTO_TRACE_SYS_FUNC_EXIT, (unsigned)this_fn, (unsigned)call_site );

>    }
> 
> So now let us look at the results from a k-trace:
> 
> 197147, 5s 561us, (393236) (7), Function Enter, function_addr 0x1041a4 call_site 0x15c8e4
> 197148, 5s 575us, (393236) (7), User Event 254, string  d0 0 d1 0
> 197151, 5s 613us, (393236) (7), Function Enter, function_addr 0x1076adc call_site 0x15c8e4
> 197152, 5s 625us, (393236) (7), Function Enter, function_addr 0x1041a4 call_site 0x15c8e4
> 
> Line 1 is from compiler generated call to __cyg_profile_func_enter
> Line 2 is the user TraceEvent 254 you see in the source
> Line 3 is the self made enter event using a call to get_my_addr()
> Line 4 is the self inserted event using the f-ptr
> 
> Looking at "function_addr" you see different values,
> the problem is that the reported addresses are wrong expect the one that i get by calling get_my_addr()
> The load address of the shared object from pidin mem is 0x1075000
> you see the reported addresses do not match the load address.
> 
> any suggestions?
> hp
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post36822
> 

-- 
cburgess@qnx.com
Hans-Peter Reichert
08/27/2009 3:48 PM
post36825
Re: problem with -finstrument-functions and qcc 4.2.4 on ARM   
but that's not what it should!
Colin Burgess(deleted)
08/27/2009 3:50 PM
post36826
Re: problem with -finstrument-functions and qcc 4.2.4 on ARM   
Well let's confirm that that's what it's doing, first :-)

Hans-Peter Reichert wrote:
> but that's not what it should!
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post36825
> 

-- 
cburgess@qnx.com
Hans-Peter Reichert
08/27/2009 3:53 PM
post36827
Re: problem with -finstrument-functions and qcc 4.2.4 on ARM   
OK, and let's also confirm that it is different from otherplatforms like Sh or x86
;-)
> Well let's confirm that that's what it's doing, first :-)
> 
> Hans-Peter Reichert wrote:
> > but that's not what it should!
> > 
> > 
> > 
> > _______________________________________________
> > 
> > General
> > http://community.qnx.com/sf/go/post36825
> > 
> 
> -- 
> cburgess@qnx.com
Aleksandar Ristovski(deleted)
08/27/2009 4:16 PM
post36830
Re: problem with -finstrument-functions and qcc 4.2.4 on ARM   
It will probably be the same.

I believe that what is happening is that address-of the 
function is calculated. There must be a R_ARM_COPY 
relocation for any site where address-of is taken so that 
addresses match wherever they were taken from. TO confirm 
this, you can print address of foo from your executable, it 
should be the same as reported by trace.

I wonder if this would work: to calculate real address of 
the function you can do

void __cyg_profile_func_enter (void *this_fn, void *call_site) {
       TraceEvent( _NTO_TRACE_INSERTSCLASSEVENT, 5, 
_NTO_TRACE_SYS_FUNC_ENTER, 
(unsigned)__builtin_return_address(0), (unsigned)call_site );
    }

this should give address very close to real function start 
(the address calculated should point to after prologue + 
call to __cyg_profile_func_enter).


---
Aleksandar

Hans-Peter Reichert wrote:
> OK, and let's also confirm that it is different from otherplatforms like Sh or x86
> ;-)
>> Well let's confirm that that's what it's doing, first :-)
>>
>> Hans-Peter Reichert wrote:
>>> but that's not what it should!
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> General
>>> http://community.qnx.com/sf/go/post36825
>>>
>> -- 
>> cburgess@qnx.com
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 
> General
> http://community.qnx.com/sf/go/post36827
>
Hans-Peter Reichert
08/28/2009 3:42 AM
post36848
Re: problem with -finstrument-functions and qcc 4.2.4 on ARM   
Take a look at what I posted in my exampe,
that one is already doing all this once by using get_my_addr() and once using foo() symbol directly.
But this is missing my intention, I think this is a bug.
With this misfunction Address Translation feature is not working for ARM,
also Application Profiler feature is also not working.
Ask Elena whether she has an Application Profiler test case for a shared object on ARM.

/hp
Aleksandar Ristovski(deleted)
08/28/2009 9:45 AM
post36866
Re: problem with -finstrument-functions and qcc 4.2.4 on ARM   
Hans-Peter Reichert wrote:
> Take a look at what I posted in my exampe,
> that one is already doing all this once by using get_my_addr() and once using foo() symbol directly.


The point is that called instrumentation function 
(_cyg_profile_func_enter) should call __builtin_return_address.


I just compiled and run this:

void __cyg_profile_func_enter (void *this_fn, void *call_site) {
	printf("%s: this_fn: 0x%08x  return_addr: 0x%08x 
call_site: 0x%08x\n",
		   __func__, this_fn, __builtin_return_address(0), call_site);
}

The output is:
__cyg_profile_func_enter: this_fn: 0x0010054c  return_addr: 
0x010844b4  call_site: 0x001007a4


> But this is missing my intention, I think this is a bug.

Maybe it is still a bug. Have you used our profiling 
solution? I believe you can achieve the same effect with our 
profiling solution by defining "QPROF_KERNEL_TRACE=1" env. var.

> With this misfunction Address Translation feature is not working for ARM,
> also Application Profiler feature is also not working.
> Ask Elena whether she has an Application Profiler test case for a shared object on ARM.

Will do.

Thanks,

Aleksandar
Hans-Peter Reichert
08/31/2009 4:14 AM
post36926
Re: problem with -finstrument-functions and qcc 4.2.4 on ARM   
> The point is that called instrumentation function 
> (_cyg_profile_func_enter) should call __builtin_return_address.
It can, but it should not have to.
It is defined that it gets the proper address.

I still think that this is a bug,
and I did a 2nd test for a simple binary (not a .so)
For this test it is working as expected.

> 
> I just compiled and run this:
> 
> void __cyg_profile_func_enter (void *this_fn, void *call_site) {
> 	printf("%s: this_fn: 0x%08x  return_addr: 0x%08x 
> call_site: 0x%08x\n",
> 		   __func__, this_fn, __builtin_return_address(0), call_site);
> }
I already did it this way by using the get_my_addr() implementation, see source from first post

> 
> Maybe it is still a bug. Have you used our profiling 
> solution? I believe you can achieve the same effect with our 
> profiling solution by defining "QPROF_KERNEL_TRACE=1" env. var.
> 
I used it several times.
But in the past there were allways problems in profiling shared objects
The QPROF_KERNEL_TRACE=1 is not all you need, you also need at least QPROF_NO_MAIN=1
otherwise profiling wont start because main() is not instrumented,
but though, problems remained and I simply used my own minimal implementation.
Aleksandar Ristovski(deleted)
08/31/2009 9:48 AM
post36952
Re: problem with -finstrument-functions and qcc 4.2.4 on ARM   
Hans-Peter Reichert wrote:
> 
>> I just compiled and run this:
>>
>> void __cyg_profile_func_enter (void *this_fn, void *call_site) {
>> 	printf("%s: this_fn: 0x%08x  return_addr: 0x%08x 
>> call_site: 0x%08x\n",
>> 		   __func__, this_fn, __builtin_return_address(0), call_site);
>> }
> I already did it this way by using the get_my_addr() implementation, see source from first post

It is not equivalent to what I suggested since your "foo" 
function has to be modified to determine its own address. 
The idea of instrumentation is to not have to modify 
functions that are subject of instrumentation.

> 
>> Maybe it is still a bug. Have you used our profiling 
>> solution? I believe you can achieve the same effect with our 
>> profiling solution by defining "QPROF_KERNEL_TRACE=1" env. var.
>>
> I used it several times.
> But in the past there were allways problems in profiling shared objects
> The QPROF_KERNEL_TRACE=1 is not all you need, you also need at least QPROF_NO_MAIN=1
> otherwise profiling wont start because main() is not instrumented,
> but though, problems remained and I simply used my own minimal implementation.

Interesting, from the current profiling library code, I see 
we now ignore QPROF_NO_MAIN. It should not have any effect 
at all. The library should just start profiling when first 
instrumented function is executed (no matter where it is). 
Tracing will auto start if one of QPROF_KERNEL_TRACE or 
QPROF_FILE are given and unless QPROF_AUTO_START is set to '0'

What version are you using? What exactly was the problem, 
maybe we can work on that and get it fixed for you?




Thanks,

Aleksandar
Hans-Peter Reichert
08/31/2009 10:09 AM
post36953
AW: problem with -finstrument-functions and qcc 4.2.4 on ARM   
>It is not equivalent to what I suggested since your "foo" 
>function has to be modified to determine its own address. 
>The idea of instrumentation is to not have to modify functions 
>that are subject of instrumentation.

that was only for testing :-)

>
>> 
>>> Maybe it is still a bug. Have you used our profiling solution? I 
>>> believe you can achieve the same effect with our profiling solution 
>>> by defining "QPROF_KERNEL_TRACE=1" env. var.
>>>
>> I used it several times.
>> But in the past there were allways problems in profiling shared 
>> objects The QPROF_KERNEL_TRACE=1 is not all you need, you 
>also need at 
>> least QPROF_NO_MAIN=1 otherwise profiling wont start because 
>main() is 
>> not instrumented, but though, problems remained and I simply 
>used my own minimal implementation.
>
>Interesting, from the current profiling library code, I see we 
>now ignore QPROF_NO_MAIN. It should not have any effect at 
>all. The library should just start profiling when first 
>instrumented function is executed (no matter where it is). 
>Tracing will auto start if one of QPROF_KERNEL_TRACE or 
>QPROF_FILE are given and unless QPROF_AUTO_START is set to '0'
>
>What version are you using? What exactly was the problem, 
>maybe we can work on that and get it fixed for you?
I didn't test the latest version
it has been a problem up to ... can't remember that excatly,
but I had a discussion on that in IDE forum with Elena

I will give current libprofilingS.a a try ...

but still behaviour is not as defined ;-)

cheers
hp 
 
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Huls, Michael Mauser
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad | 
Local Court Mannheim: Register No. 361395

 
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat 
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have 
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************
Aleksandar Ristovski(deleted)
08/31/2009 10:46 AM
post36957
Re: AW: problem with -finstrument-functions and qcc 4.2.4 on ARM   
Hans-Peter Reichert wrote:
> 
> but still behaviour is not as defined ;-)

You may be right, maybe there is a way to do a better job in 
gcc, but right now this is how it works.

I will repeat that you can get good results with current gcc 
  by simply using  __builtin_return_address(0) as I suggested.

You could even use dladdr in your __cyg_profile_... 
implementation to retrieve symbol name; then use dlsym again 
to calculate exact function entry.


---
Aleksandar

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems