Re: opreport support for not-C++ symbols

[Nikolay I. <Nikolay.Igotti@Sun.COM>]

John Levon wrote:

>On Tue, May 24, 2005 at 07:30:46PM +0400, Nikolay Igotti wrote:
>
>  
>
>>Hmm, in fact we implemented somewhat simple architecture, based on JVM TI.
>>    
>>
>
>I hope you realise that any Java-specific approach isn't going to fly
>here. We need easy support for multiple JITs (in particular Mono).
>
>  
>
 Sure, it's no more Java specific than it should be.
What is really requested is:
1. VM creates MAP_PRIVATE  mapping of some temporary file over its 
executable code regions.
2.  some kind of VM or agent code listens for code generation events, 
and checks where
     this particular VM symbol belongs, and writes such information on disk.

>>contains symbols not expected to be presented in ELF symbol table
>>    
>>
>
>Can you elaborate?
>
>  
>
 Sorry, made a mistake here. I thought there's a limitation on 
acceptable ELF symbol name,  and it seems
it's just an arbitrary null-terminated string.

>>- hard to maintain, as have to be supported for all arches somewhat 
>>separately
>>    
>>
>
>Not at all, we use libbfd to write the ELF files, so there's no
>arch-specific stuff.
>
>  
>
BTW, do you have an example of  ELF file generator using libbfd?

>- symbols and their addresses
>- (possibly) the generated instructions for each symbol
>- (possibly) debug information
>
>  
>
 I think you're right. ELF (or some kind of i18n'ed ELF) seems  to be 
pretty good fit.
The only problem is reuse of the same VMA ranges for different symbols, 
and this one can be worked around
by mapping different file when we reuse memory region for other JITted 
code. This way profile will automatically send results to another file.

  Thanks,
     Nikolay.