From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932480AbbFBOqe (ORCPT ); Tue, 2 Jun 2015 10:46:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50864 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759471AbbFBOqV (ORCPT ); Tue, 2 Jun 2015 10:46:21 -0400 Date: Tue, 2 Jun 2015 09:46:18 -0500 From: Josh Poimboeuf To: Ingo Molnar Cc: Andy Lutomirski , Jan Beulich , Borislav Petkov , Peter Zijlstra , Ingo Molnar , Brian Gerst , =?utf-8?B?RnLDqWTDqXJpYw==?= Weisbecker , Thomas Gleixner , Linus Torvalds , Denys Vlasenko , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , "Frank Ch. Eigler" Subject: Re: [PATCH] x86/debug: Remove perpetually broken, unmaintainable dwarf annotations Message-ID: <20150602144618.GA24773@treble.redhat.com> References: <5566EBE7020000780007E659@mail.emea.novell.com> <20150528090133.GA469@gmail.com> <5566FFDD020000780007E711@mail.emea.novell.com> <20150528112017.GA28196@gmail.com> <55671D63020000780007E885@mail.emea.novell.com> <20150528131743.GA9496@gmail.com> <20150601194516.GA6110@treble.redhat.com> <20150602055706.GA27094@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150602055706.GA27094@gmail.com> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 02, 2015 at 07:57:06AM +0200, Ingo Molnar wrote: > * Andy Lutomirski wrote: > > On Mon, Jun 1, 2015 at 12:45 PM, Josh Poimboeuf wrote: > > > On Fri, May 29, 2015 at 10:47:31AM -0700, Andy Lutomirski wrote: > > >> FWIW, musl is considering some kind of automatic annotation scheme: > > >> > > >> http://www.openwall.com/lists/musl/2015/05/13/5 > > > > > > Thanks for the link! I found a newer version of it here: > > > > > > http://www.openwall.com/lists/musl/2015/05/31/5 > > > > > > Overall I think that script is a really good solution. > > > > > > From what I can tell, it tracks the CFA (stack pointer) perfectly. > > > (Which is actually pretty straightfoward if you just hook into function > > > entry/exit, push/pop, and add/sub to rsp). > > > > > > It also does a nice job at making a best effort at tracking the caller's > > > register values (which are less important than CFA but still nice to > > > have). > > > > It might be nice to be able to reliably unwind out from an exception / interrupt > > / syscall frame into userspace or into the kernel code that trapped, complete > > with registers. > > > > In any event, we'll almost certainly have to manually annotate these weird types > > of entries. I wonder if we could manage to annotate just the entry parts and > > let a magic script do the rest. > > Even the entry parts we could help without uglifying the code: > > - either by adding a 'RET' instruction after IRET/SYSRET/SYSEXIT/etc. that the > tooling can recognize as 'return from function'. That's much nicer than ugly > annotations. > > - enhancing the tooling script to also recognize these instructions as function > returns - because they _are_ function returns. I think the problem with the entry code (and other non-function asm code) is that it's quite spaghetti-esque, with lots of jumps, returns, calls, etc to random places. There aren't enough constraints which would help the tooling make sense of where execution begins and ends, when registers are saved or trashed, etc. Maybe over time we can figure out what constraints (and/or annotations) are needed there. -- Josh