From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753124AbaKFRAx (ORCPT ); Thu, 6 Nov 2014 12:00:53 -0500 Received: from mail-la0-f51.google.com ([209.85.215.51]:38285 "EHLO mail-la0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751465AbaKFRAu (ORCPT ); Thu, 6 Nov 2014 12:00:50 -0500 MIME-Version: 1.0 In-Reply-To: <545B5CFC0200007800045463@mail.emea.novell.com> References: <5458A9600200007800044AE5@mail.emea.novell.com> <54592BB4.4040703@amacapital.net> <545A5AA402000078000C1067@mail.emea.novell.com> <545B5CFC0200007800045463@mail.emea.novell.com> From: Andy Lutomirski Date: Thu, 6 Nov 2014 09:00:28 -0800 Message-ID: Subject: Re: [PATCH, RFC] x86: also CFI-annotate certain inline asm()s To: Jan Beulich Cc: Ingo Molnar , Thomas Gleixner , Tony Jones , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 6, 2014 at 2:35 AM, Jan Beulich wrote: >>>> On 05.11.14 at 18:23, wrote: >> On Wed, Nov 5, 2014 at 9:13 AM, Jan Beulich wrote: >>>>>> Andy Lutomirski 11/04/14 8:40 PM >>> >>>>On 11/04/2014 01:24 AM, Jan Beulich wrote: >>>>> The main obstacle to having done this long ago was the need to >>>>> determine whether annotations are needed in the first place: They need >>>>> to be avoided when a frame pointer got set up. Since I can't see a way >>>>> to determine this before the compilation phase, this is being achieved >>>>> by inspecting the memory address generated by the compiler in an >>>>> interposed assembler macro. Of course this isn't really nice code, and >>>>> this the main reason I'm posting this as RFC only at this point (with >>>>> the hope that maybe someone has an idea of how to achieve the same >>>>> thing in a more elegant way). >>>> >>>>Ask binutils for help? >>> >>> Binutils know as little about the code the compiler generated as we do. >> >> Could binutils add a >> .cfi_adjust_cfa_offset_if_the_cfa_depends_on_sp_right_now directive? >> IIUC, the issue is that, when you push, you don't want the canonical >> frame address to change as a result, but you just changed the stack >> pointer, so if the CFA is computed as an offset from the stack pointer >> in the current context, that offset needs to change. > > While that's theoretically doable, I don't think this would be a > reasonable approach. > I'll defer to your judgment about this. You clearly know a lot more about cfi than I do :) That being said, I've occasionally wanted the ability to do things like this in userspace code, so maybe it wouldn't be a terrible feature request. >> Alternatively, is there any sane way to get the inline asm to act as >> though it creates an entirely new frame? It would have CFA == rsp >> initially (or rsp + 8 or whatever -- I can never keep track of what >> the CFA is actually supposed to point to) and unwind instructions that >> tell the unwinder that the caller pc is at a known address instead of >> being stuck in the stack frame? > > No, that can't work: You'd have to > - end the previous function (from the CFI engine's pov) > - start a new function > - do what you suggest above > - end the "nested" function > - start a continuation function for the subsequent compiler > generated code > - magically know the state of things at the point the original > function got (artificially) ended Fair enough. Empirically, sticking this in the middle of a function doesn't work: .cfi_remember_state .cfi_endproc .cfi_startproc .cfi_restore_state Oh, well. --Andy