Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1163016AbbKTTc0 (ORCPT ); Fri, 20 Nov 2015 14:32:26 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:54617 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760691AbbKTTcY (ORCPT ); Fri, 20 Nov 2015 14:32:24 -0500 Date: Fri, 20 Nov 2015 20:32:17 +0100 From: Peter Zijlstra To: Brian Robbins Cc: Ingo Molnar , Arnaldo Carvalho de Melo , "linux-kernel@vger.kernel.org" , Stephane Eranian Subject: Re: [PATCH] perf: Fallback to JIT support for mmap'd non-ELF binaries. Message-ID: <20151120193217.GW3816@twins.programming.kicks-ass.net> References: <1447960147-2681-1-git-send-email-brianrob@microsoft.com> <20151119193101.GQ3816@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1930 Lines: 41 On Thu, Nov 19, 2015 at 11:45:45PM +0000, Brian Robbins wrote: > 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. *groan* you just had to go and invent yet another executable format, right? :-) > 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. As I think Stephane explained, this is only required if you need to match up kernel and userspace timestamps, which is important for dynamic code generation, less so for static code in a weird format. So what the new JIT stuff does is online write 'fake' ELF files with symbol sections and (optionally?) dwarf debug info for line numbers. Since you don't dynamically generate code, you can offline generate these ELF files and redirect the symbol parser bits to that (we already look for debug ELF files in various locations), or... > 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. Since, someone somewhere needs to go parse this funny new file format anyhow to either generate /tmp files or fake ELF files or whatever, you might as well put that decoder in perf? Or just ship these fake ELF files in /usr/lib/debug/ or whatever the 'right' location for the distro at hand is. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/