From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932712AbaKERXa (ORCPT ); Wed, 5 Nov 2014 12:23:30 -0500 Received: from mail-lb0-f171.google.com ([209.85.217.171]:56944 "EHLO mail-lb0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932696AbaKERX2 (ORCPT ); Wed, 5 Nov 2014 12:23:28 -0500 MIME-Version: 1.0 In-Reply-To: <545A5AA402000078000C1067@mail.emea.novell.com> References: <5458A9600200007800044AE5@mail.emea.novell.com> <54592BB4.4040703@amacapital.net> <545A5AA402000078000C1067@mail.emea.novell.com> From: Andy Lutomirski Date: Wed, 5 Nov 2014 09:23:06 -0800 Message-ID: Subject: Re: [PATCH, RFC] x86: also CFI-annotate certain inline asm()s To: Jan Beulich Cc: Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , tonyj@suse.de, "linux-kernel@vger.kernel.org" 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 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. 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? > >>Is the issue that the CFI annotation you need is different depending on >>whether there's a frame pointer or not? > > No - as said above, they need to be avoided altogether when there's a > frame pointer. > >> If so, can you add some >>comments so that mere asm mortals have some prayer of understanding how >>your magic works and what the desired output annotations are in the >>various cases? > > Honestly I have a hard time seeing where comments would help here. Plus > the difficult part isn't how the annotations look like, but (see above) simply > whether to emit them at all. It could be something simple like an example of what the inputs to the asm macros are in the two cases. Currently even figuring out where those inputs come from involves following a big tangle of C preprocessor stuff, and I don't know what it's supposed to output, and what that's supposed to do the expansions in the inline asm, and how that ends up influencing the gas macros. I.e. I sort of expect I'll need to want to one of these things some day, and I'd like a couple pointers :) --Andy