Project Home
Project Home		 Trackers
Trackers		 Documents
Documents		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
IDE/Discussion/General/Application profiler for dll files/List of Posts
Forum Topic - Application profiler for dll files: (4 Items)
   
Update
Akash Goswami(deleted)
03/08/2010 8:11 AM
post48992
Application profiler for dll files   
Hello IDE Team,


I am trying to profile a dll file using function instrumentation using IDE4.6.
I use following compile time flags
CCFLAGS += -fno-builtin-log  -g -p -O0 -finstrument-functions 
LDFLAGS += -p -lprofilingS 

My dll is opened by io-pkt using dl_open and is mapped to an address 0xfe381000.
The app.ptrace output generated by profiler is written using this address.
Here is the first few lines of the output ptrace file
===================================
QPT 1.2 text
init 23c3460 0 491913175298 148550129078 149088290501 3975
dump fe412544
then fe3206b4
loading ldqnx.so.2 fe300000 501708 9a
loading devnp-p40xx.so fe381000 673864 b2
enter fe3932fc 480d4bfc 2 cf 6
enter fe39593c fe393404 2 1b7 6
enex fe3959a4 fe395944 2 1c8 +a9 6
exit fe395954 fe393404 2 286 6
enter fe3962e8 fe39346c 2 29f 6
enex fe39682c fe39635c 2 704 +d79 6
exit fe3965c4 fe39346c 2 14b1 6
enter fe393838 48066114 2 2013b09f 
......
====================================
Now the problem is that Application profiler is not able to understand these address   because actual DLL would not 
contain any of these remapped address. The addresses found inactual DLL would be X-0xfe381000 because the dll has been 
remapped to this new address by caller.

My understanding is that Application profiler needs to understand that the DLL has been relocated and somehow offset all
 the addresses after enter/enex keywords from the dll load address to understand where exactly does this function maps 
to. But it is not doing that (Or may be I am not doing something correct)

Has anybody seen this problem before or ever tried to test the DLL profiling only?
 

Thanks,
Akash
Elena Laskavaia
03/08/2010 9:27 AM
post49004
Re: Application profiler for dll files   
It should map properly. It least it works on hello world style examples 
with dlopen.
Can you grep output file for "loading " keyword? It should have this for 
your library with proper relocation address.
Check to make sure this library is "Shared Library" path for launch 
(another "tool" in Tools tab in launch configuration)

Akash Goswami wrote:
> Hello IDE Team,
>
>
> I am trying to profile a dll file using function instrumentation using IDE4.6.
> I use following compile time flags
> CCFLAGS += -fno-builtin-log  -g -p -O0 -finstrument-functions 
> LDFLAGS += -p -lprofilingS 
>
> My dll is opened by io-pkt using dl_open and is mapped to an address 0xfe381000.
> The app.ptrace output generated by profiler is written using this address.
> Here is the first few lines of the output ptrace file
> ===================================
> QPT 1.2 text
> init 23c3460 0 491913175298 148550129078 149088290501 3975
> dump fe412544
> then fe3206b4
> loading ldqnx.so.2 fe300000 501708 9a
> loading devnp-p40xx.so fe381000 673864 b2
> enter fe3932fc 480d4bfc 2 cf 6
> enter fe39593c fe393404 2 1b7 6
> enex fe3959a4 fe395944 2 1c8 +a9 6
> exit fe395954 fe393404 2 286 6
> enter fe3962e8 fe39346c 2 29f 6
> enex fe39682c fe39635c 2 704 +d79 6
> exit fe3965c4 fe39346c 2 14b1 6
> enter fe393838 48066114 2 2013b09f 
> ......
> ====================================
> Now the problem is that Application profiler is not able to understand these address   because actual DLL would not 
contain any of these remapped address. The addresses found inactual DLL would be X-0xfe381000 because the dll has been 
remapped to this new address by caller.
>
> My understanding is that Application profiler needs to understand that the DLL has been relocated and somehow offset 
all the addresses after enter/enex keywords from the dll load address to understand where exactly does this function 
maps to. But it is not doing that (Or may be I am not doing something correct)
>
> Has anybody seen this problem before or ever tried to test the DLL profiling only?
>  
>
> Thanks,
> Akash
>  
>
>
>
> _______________________________________________
>
> General
> http://community.qnx.com/sf/go/post48992
>
>
Akash Goswami(deleted)
03/10/2010 1:11 AM
post49143
Re: Application profiler for dll files   
Thanks Elena,

> Can you grep output file for "loading " keyword? It should have this for 
> your library with proper relocation address.

Yes it is already there in the first few lines of trace

> > loading devnp-p40xx.so fe381000 673864 b2



> Check to make sure this library is "Shared Library" path for launch 
> (another "tool" in Tools tab in launch configuration)

Profiler seems to detect library correctly. Reason why I believe so is that if I recreate my DLL with remapped address 
(Thats is remapping the entire DLL to 0xfe381000) , then I am able to see the function names in Application profiler 
trace. 

Is there a way I can check why profiler is not able to translate address of the DLL?
Has there been any fix in the latest IDE? I may also give it a try.

BR
Akash

> Akash Goswami wrote:
> > Hello IDE Team,
> >
> >
> > I am trying to profile a dll file using function instrumentation using IDE4.
> 6.
> > I use following compile time flags
> > CCFLAGS += -fno-builtin-log  -g -p -O0 -finstrument-functions 
> > LDFLAGS += -p -lprofilingS 
> >
> > My dll is opened by io-pkt using dl_open and is mapped to an address 
> 0xfe381000.
> > The app.ptrace output generated by profiler is written using this address.
> > Here is the first few lines of the output ptrace file
> > ===================================
> > QPT 1.2 text
> > init 23c3460 0 491913175298 148550129078 149088290501 3975
> > dump fe412544
> > then fe3206b4
> > loading ldqnx.so.2 fe300000 501708 9a
> > loading devnp-p40xx.so fe381000 673864 b2
> > enter fe3932fc 480d4bfc 2 cf 6
> > enter fe39593c fe393404 2 1b7 6
> > enex fe3959a4 fe395944 2 1c8 +a9 6
> > exit fe395954 fe393404 2 286 6
> > enter fe3962e8 fe39346c 2 29f 6
> > enex fe39682c fe39635c 2 704 +d79 6
> > exit fe3965c4 fe39346c 2 14b1 6
> > enter fe393838 48066114 2 2013b09f 
> > ......
> > ====================================
> > Now the problem is that Application profiler is not able to understand these
>  address   because actual DLL would not contain any of these remapped address.
>  The addresses found inactual DLL would be X-0xfe381000 because the dll has 
> been remapped to this new address by caller.
> >
> > My understanding is that Application profiler needs to understand that the 
> DLL has been relocated and somehow offset all the addresses after enter/enex 
> keywords from the dll load address to understand where exactly does this 
> function maps to. But it is not doing that (Or may be I am not doing something
>  correct)
> >
> > Has anybody seen this problem before or ever tried to test the DLL profiling
>  only?
> >  
> >
> > Thanks,
> > Akash
> >  
> >
> >
> >
> > _______________________________________________
> >
> > General
> > http://community.qnx.com/sf/go/post48992
> >
> >
Elena Laskavaia
03/10/2010 9:25 AM
post49163
Re: Application profiler for dll files   
Sorry I don't understand what you mean by DLL with remapped address. Do 
you have a path in Shared Library path tab or not?
App Profiler needs 4 things to work correctly (mapping):
- "loading" records present in trace
- library path is set in Shared Library tab of Tools tab in launch config
- library file name be exact same as name in "loading" record
- library has to be compiled with -g and not stripped

In older versions of libprofiling binary has to be linked with -Wl,-E to 
export all symbols, because otherwise
profiling library linked twice and have two data segments, instead of 
one. Which was causing profiling
event not generating for the shared libraries (but for you they seems to 
be generated right?).
If you think it may be the case you
can also link library dynamically instead (use -llibprofiling instead of 
-llibprofilingS)

Actual address calculated as base + library offset, i.e if call is at 
0xfe381100
The base is 0xfe381000 and offset is 0x100, so it would look up in 
symbol table of library which is loaded at
this address at 0x100 and symbols is there it is mapped to this address 
0xfe381100

>   
>> Check to make sure this library is "Shared Library" path for launch 
>> (another "tool" in Tools tab in launch configuration)
>>     
>
> Profiler seems to detect library correctly. Reason why I believe so is that if I recreate my DLL with remapped address
 (Thats is remapping the entire DLL to 0xfe381000) , then I am able to see the function names in Application profiler 
trace. 
>
> Is there a way I can check why profiler is not able to translate address of the DLL?
> Has there been any fix in the latest IDE? I may also give it a try.
>
> BR
> Akash
>
>   
>

Return


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