From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755064AbdCTQIQ (ORCPT ); Mon, 20 Mar 2017 12:08:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2577 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753379AbdCTQH0 (ORCPT ); Mon, 20 Mar 2017 12:07:26 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 78E1267EB7 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 78E1267EB7 Date: Mon, 20 Mar 2017 11:07:19 -0500 From: Josh Poimboeuf To: Jiri Slaby Cc: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org, Boris Ostrovsky , Juergen Gross , xen-devel@lists.xenproject.org, "Rafael J. Wysocki" , Len Brown , Pavel Machek , linux-pm@vger.kernel.org Subject: Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for data Message-ID: <20170320160719.57xlo2stclruyzwo@treble> References: <9ea5e137-61f9-dccc-bb9d-ac3ff86e5867@suse.cz> <20170320123222.15453-1-jslaby@suse.cz> <20170320123222.15453-2-jslaby@suse.cz> <20170320133243.5rvae6liwwqg4dve@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 20 Mar 2017 16:07:23 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 20, 2017 at 04:32:09PM +0100, Jiri Slaby wrote: > On 03/20/2017, 02:32 PM, Josh Poimboeuf wrote: > > On Mon, Mar 20, 2017 at 01:32:14PM +0100, Jiri Slaby wrote: > >> This is a start of series to cleanup macros used for starting functions, > >> data, globals etc. across x86. When we have all this sorted out, this > >> will help to inject DWARF unwinding info by objtool later. > >> > >> The goal is forcing SYM_FUNC_START to emit .cfi_startproc and > >> SYM_FUNC_END to emit .cfi_endproc. Automatically at best. > > > > Do we still want to emit .cfi_startproc/endproc from the macro? From > > our last discussion, that seemed to be up in the air. > > > > https://lkml.kernel.org/r/20170217211804.j6l2d7t5mfzqzmbt@treble > > "Automatically at best" above means "completely from objtool". I am > still uncertain whether it will work 100% or we would have to help by > generating some pieces from the added macros. In particular, the ALIASes > are evil which cause harm here: > > fun_alias: > fun: > > .size fun, .-fun > .type fun STT_FUNC > .size fun_alias, .-fun_alias > .type fun_alias STT_FUNC > > Both cannot create (overlapping) .cfi_startproc/endproc, only the inner > shall. > > But it seems so far, that we might be able to deal with all of that from > objtool... (I have not been thinking about this particular thing deep > enough yet.) Some sort of "from the last label that is marked as > STT_FUNC till its .size" might work. Ok. > > What did you think about making CFI read-only for .c object files and > > write-only for .S object files? > > There are those functions like sync_core() or native_save_fl() with > inline asm. And they seem to need a) read-write support, or b) manual > annotation. I would like to avoid b) for sure. Ah, so I guess those inline asm functions cause problems because they muck with the stack pointer with pushes and pops? I don't think manual annotation of inline asm would be so bad. IIUC, it would only mean replacing the pushes and pops with a macro which does the CFI-annotated version, like PUSH_CFI and POP_CFI. And the benefit would be that objtool doesn't have to try to rewrite a bunch of .c object files. Objtool read-write worries me because it gives more responsibility to objtool. It could be tricky to insert CFI instructions within the ones already created by gcc. Also, while unlikely, a bug in objtool could theoretically corrupt an object file and brick the kernel. Also I wonder how all those extra file writes would affect build performance. If at all possible, I would rather objtool stay out of the way of the compiler and let gcc do its job of generating CFI. -- Josh