[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SN1PR0301MB15982C2861CC002B4EAB1A47C81B0@SN1PR0301MB1598.namprd03.prod.outlook.com>
Date: Thu, 19 Nov 2015 23:45:45 +0000
From: Brian Robbins <brianrob@...rosoft.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH] perf: Fallback to JIT support for mmap'd non-ELF
binaries.
From: Peter Zijlstra <peterz@...radead.org>
Sent: Thursday, November 19, 2015 11:31 AM
To: Brian Robbins
Cc: Ingo Molnar; Arnaldo Carvalho de Melo; linux-kernel@...r.kernel.org; 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.
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists