search for: recordingjiteventlisten

...tter 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 FunctionEmittedEvent { + // Indices are local to the RecordingJITEventListener, since the + // JITEventListener interface makes no guarantees about the order of + // calls between Listeners. + int Index; Use "unsigned" instead of "int"? Can index ever be negative? Evan On Jun 24, 2009, at 1:26 PM, Jeffrey Yasskin wrote: > Ack, sorry. I should h...

...the address with the performance > tools? We're pushing to be more thread safe. As Eric said, this is just moving existing code, and it's #ifdef'ed out. I'll let the Shark folks invent a better solution. :) > +struct FunctionEmittedEvent { > +  // Indices are local to the RecordingJITEventListener, since the > +  // JITEventListener interface makes no guarantees about the order of > +  // calls between Listeners. > +  int Index; > > Use "unsigned" instead of "int"? Can index ever be negative? Sure, it's unsigned now. > On Jun 24, 2009, at 1:26 PM...

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