Re: [PATCH] perf: Fallback to JIT support for mmap'd non-ELF binaries.

[Stephane Eranian]

On Thu, Nov 19, 2015 at 3:45 PM, Brian Robbins <brianrob@xxxxxxxxxxxxx> wrote:
>
> From: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> Sent: Thursday, November 19, 2015 11:31 AM
> To: Brian Robbins
> Cc: Ingo Molnar; Arnaldo Carvalho de Melo; linux-kernel@xxxxxxxxxxxxxxx; Stephane Eranian
> Subject: Re: [PATCH] perf: Fallback to JIT support for mmap'd non-ELF binaries.
>
> > On Thu, Nov 19, 2015 at 11:09:07AM -0800, Brian Robbins wrote:
> > > Programs can execute code contained in files that don't conform
> > > to the ELF standard.  This is common for cross-platform runtimes
> > > that support ahead-of-time compilation.  In this case, perf is
> > > unable to resolve addresses to symbolic names, as the format of
> > > the mmap'd file is unknown to perf.
>
> > I'm assuming you're using PECOFF? Why not teach perf to read those?
>
> > Surely there's a library that can parse that stuff, it seems to me Wine
> > for one needs fairly decent support for this, also GDB (and other
> > toolchain bits) on Windows targets.
>
> > Its just that I was hoping we could move towards getting rid of those
> > /tmp files now that we have much better JIT support.
>
> Hi Peter,
>
> Thank you for the feedback.  The file format is similar to PE, but is not identical.  So, we would be implementing something very scoped, which doesn't feel right to me.
>
> I am interested in the new JIT support, however my understanding from the information that I've read is that it requires kernel support in 4.x, though I can't seem to find where I read that.  I want to make sure that this works on older kernels (3.x) as well.
>
You need 4.1 if you have a situation where your JIT may recompile code
multiple times. The key difference is that
with 4.1 you can use the same timestamp clock source for both the JIT
runtime and the kernel perf_event subsystem.
That makes it possible to correlate samples from the JIT with samples
from the hardware. Without that, you may not
get correct symbolization if the code is re-jitted or moved.

>
> The reason I went with this approach is because it is simple for runtimes to implement and has no requirement that perf understand the file format.  I am open to feedback if there is a preferred solution that would still work for older kernels as well.
>
> Thanks.
> -Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/