Hi all, Carl Love <cel <at> us.ibm.com> writes:
> > On Mon, 2015-01-12 at 10:58 -0700, David Ahern wrote: > > On 1/12/15 10:22 AM, Carl Love wrote: > > > Ah, this is the ioctl patch you had mentioned you mentioned previously. > > > I hadn't found the patch before. Yes, this looks like it would work. I > > > will see if I can get a prototype working with this patch. Thanks. > > > > > > > If you need to shove samples into perf (versus mmap updates) I suspect > > the prctl system call will have way to much overhead. In that case > > perhaps processes could export a shared memory buffer that a perf > > session could attach -- another aux buffer similar to what itrace needs. > > But then that brings in the perf_clock issue; samples would need to have > > the same time basis as kernel generated samples. > > > > I have the kernel patch by Pawel working to send the source file name, > the code address and the code size to perf and insert a new record into > the perf.data file as a uevent. In the perf code, I have added code in > file util/session.c, perf_session__deliver_event() to call a function to > process the new event data. > > I am trying to start with just getting the samples mapped to the elf > file. I will try to implement mapping the samples to a specific source > code line later. > > My thought is I need to take the data and create a "fake" elf file entry > with the file name, start address and code size so the will be able to > map sample addresses to the elf file for the java method. I am > struggling to understand code flow for the perf record, specifically > when the elf files get read, mapping a sample to an elf file, etc. It > is not clear to me how I would go about creating the fake elf file and > how to make it visible for use by the perf record tool. Any pointers > and guidance would be appreciated. Thanks. FWIW, the HP caliper tool on HP-UX/IPF has some similar functionality to show Java function names and show an annotated source code in the function disassembly part of the report. Caliper runs as a separate process measuring the target process by tracing it, and the target process can register dynamically generated code/module with caliper. JVM code for HP-UX was modified to use this framework to register the dynamically generated methods with caliper at runtime. As for the source code annotation for JVM generated code through JIT compiler, we use a Java option to dump the annotated assembly from JIT into a file, and also generate an index file to search the assembly dump given an address. The index file is somewhat similar to a dwarf line table, but it's just a plain text file and not in an elf format. When caliper shows the disassembly, it looks up for the index file and finds the relevant annotation to display for the address ranges in the assembly. Since the annotated dump comes from Java itself, it contains information like source line number, prologue region etc. For example, if it is a safepoint, the information about Oop maps, bytecode index, etc are available in those annotations which are very JVM specific. Basically, the idea was to merge the JVM assembly annotations along with the caliper report. I am not familiar with perf, but just wanted to bring up this information to this forum to see if this could be an approach to consider for the samples to source co-relation. The source co-relation comes from the JIT compiler like JVM, and can probably made into annotation records. Along with this, the index file could be used to co- relate the annotation records to the address ranges seen in samples. Regards, Sujoy -- To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
