search for: jitsymbolt

...well as the address range it occupies. This allows the client to map +/// from a PC value to the name of the function. +struct JitSymbolEntry { A nitpick. Please rename it to "JITSymbolEntry" for naming consistency. + +// This is a public symbol so the performance tools can find it. +JitSymbolTable *__jitSymbolTable; + Hmm. Is there a better solution? From what I can tell, the event listener is responsible for allocating symbol table memory so it effectively owns it. Can we register the address with the performance tools? We're pushing to be more thread safe. +struct FunctionE...

...> +/// from a PC value to the name of the function. > +struct JitSymbolEntry { > > A nitpick. Please rename it to "JITSymbolEntry" for naming consistency. Done, although this is just a move. > + > +// This is a public symbol so the performance tools can find it. > +JitSymbolTable *__jitSymbolTable; > + > > Hmm. Is there a better solution? From what I can tell, the event > listener is responsible for allocating symbol table memory so it > effectively owns it. Can we register the address with the performance > tools? We're pushing to be more thread s...

Ack, sorry. I should have sent this to llvm-commits instead. :-P Followups there please. On Wed, Jun 24, 2009 at 12:02 PM, Jeffrey Yasskin<jyasskin at google.com> wrote: > I intend to use this to support oprofile's ability to symbolize JITted > code through the interface described at > http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I > believe the interface

I intend to use this to support oprofile's ability to symbolize JITted code through the interface described at http://oprofile.sourceforge.net/doc/devel/jit-interface.html. I believe the interface will also be useful for gdb support. I'm considering adding some flags to the JITEventListener to let the JIT avoid collecting information no listener is going to use, but I won't do that