Analyzers
Talk to fellow users of Intel Analyzer tools (Intel VTune™ Profiler, Intel Advisor)

Creating custom symbol info for VTune

Eric_K_4
Beginner
452 Views

I am using VTune Amplifier XE 2011 on Linux. I am profiling an application that creates custom code on the fly and executes it. I want to be able to see the custom code in the profile results. So, i take the ELF file for the application, modify it to add DWARF info records for the new functions, and then re-resolve the results. Unfortunately, it still doesn't show my custom functions in the profile results. All I get is [Unknown stack frame]. First of all, is there anyway that I can see which addresses were resolved to "Uknown stack frame"? Second, what is the minimum info I need to have in the ELF file DWARF sections to be able to resolve the addresses properly? I add a new compilation unit and then subroutine entries with DW_AT_name, DW_AT_external, DW_AT_low_pc, and DW_AT_high_pc. In addition, the compilation unit specifies DW_AT_name, DW_AT_low_pc, and DW_AT_high_pc.

Thanks!

0 Kudos
6 Replies
Peter_W_Intel
Employee
452 Views
Here is my tips: 1. VTune can profile your program, because your program was loaded by the tool - or process was attached by the tool 2. VTune can know DWARF format file, but you said that generated code on the fly and execute it. Did it mean that custom code was not generated in file, and executed in your process memory? VTune can understand your custom code when executing - if your custom code (in file) was loaded to OS and it is child-process of your program. 3. If custom code is not your child process, you can use attach-to-process mode to profile custom code process 4. If your custom was driven by your program in your specific mode (I don't know in detail) - it will not be supported. Anyway, custom code should be loaded and run in one of these modes - dynamical library load, new child process spawn, new created process. Regards, Peter
0 Kudos
Eric_K_4
Beginner
452 Views
OS is Linux The custom code is not in a shared object (equivalent of DLL on Windows). It is not in a new created process. It is not in a child process. The custom code is created in a buffer that is created at runtime by the application. It is created with permissions set to allow execution. During run time the application creates a custom function and places the code into this buffer. The application is written in C and occasionally uses a function pointer to call the custom function that is in the buffer. The custom function is not in the object file that was loaded since it is created dynamically during program execution. I want to know how much time I spend in the custom function. How can I figure this out with VTune? When I run the program in VTune I can see profile results showing the known functions and then a bunch of "Unknown" as well. I would really like to know which addresses VTune is putting into this Unknown category. I know, after the program has run, where my custom code was placed in memory. If I could access the addresses that VTune cannot place then I could match them to my custom code manually. What I was trying to do was modify the object file and then re-finalize (re-resolve) the symbols. After the program has run I know where the custom code was placed. So, I post process the object file and place extra debug information into it to describe where the custom function was. I was hoping that I could then re-resolve the results and it would show my custom function in the results.
0 Kudos
Peter_W_Intel
Employee
452 Views
Thank you let me know working mechanism. [During run time the application creates a custom function and places the code into this buffer. The application is written in C and occasionally uses a function pointer to call the custom function that is in the buffer] There is no symbol info associated to your program, actually that buffer became the function entry address. [So, I post process the object file and place extra debug information into it to describe where the custom function was.] 1. You might try re-resolve on your new program (not obj) with modified debug info. 2. Use lightweight-hotspots to find hot addresses in [unknown], which locates in your new program module, can you view assembly source line - pointed to buffer, event contents are "nop"? But you know where instructions are...
0 Kudos
Eric_K_4
Beginner
452 Views
You said: "You might try re-resolve on your new program (not obj) with modified debug info." This is exactly what I am trying to do. Not sure why you differentiate between program and obj. The program is an ELF object file. That is what I add debug information to. This thread was started with the question about why this isn't working. You also said: "Use lightweight-hotspots to find hot addresses in [unknown], which locates in your new program module, can you view assembly source line - pointed to buffer, event contents are "nop"? But you know where instructions are..." When I use lightweight hotspots I get an entry for [Outside any known function] in module [Unknown]. If I try to view source I get the message "Failed to show source and assembly code.". I wish I could see the addresses, but it doesn't show them. Is there a way to see the addresses???
0 Kudos
Peter_W_Intel
Employee
452 Views
If module is [Unkown] - there is no way to go assembly view.
0 Kudos
Mark_D_Intel
Employee
452 Views
Eric, Not sure if you're still working on this, but it the JIT profiling API might be helpful - some documentation here: http://software.intel.com/sites/products/documentation/hpc/amplifierxe/en-us/2011Update/lin/ug_docs/index.htm#GUID-17D7238B-DD19-45DB-B5E0-D9B344D1BE96.htm I suspect the reason your original approach doesn't work is that the bounds of the shared objects are captured by VTune at module load time. The dynamically created functions fall outside these ranges, so VTune doesn't what module they belong to. And without knowing which module to look in, it won't be able to find the added debug info.
0 Kudos
Reply