From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935066AbdBQVSI (ORCPT ); Fri, 17 Feb 2017 16:18:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59288 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934861AbdBQVSH (ORCPT ); Fri, 17 Feb 2017 16:18:07 -0500 Date: Fri, 17 Feb 2017 15:18:04 -0600 From: Josh Poimboeuf To: Jiri Slaby Cc: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PREVIEW 10/10] linkage: add .cfi_{start/end}proc to ENTRY/ENDPROC Message-ID: <20170217211804.j6l2d7t5mfzqzmbt@treble> References: <20170217104757.28588-1-jslaby@suse.cz> <20170217104757.28588-10-jslaby@suse.cz> <20170217131602.pxrgfaeaanrzymnv@treble> <20170217140717.sxvt7tkvsez2pl7e@treble> <7f613a09-39f8-5477-ed5e-17024baf5876@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7f613a09-39f8-5477-ed5e-17024baf5876@suse.cz> 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.30]); Fri, 17 Feb 2017 21:18:07 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 17, 2017 at 03:26:36PM +0100, Jiri Slaby wrote: > On 02/17/2017, 03:07 PM, Josh Poimboeuf wrote: > > On Fri, Feb 17, 2017 at 02:36:15PM +0100, Jiri Slaby wrote: > >> On 02/17/2017, 02:16 PM, Josh Poimboeuf wrote: > >>> On Fri, Feb 17, 2017 at 11:47:57AM +0100, Jiri Slaby wrote: > >>>> This is just a preview, not to merged now, only later with DWARF > >>>> unwinder series. This is what the series will serve for (aside from > >>>> cleanup and unification). > >>>> > >>>> I am aware of CFI_STARTPROC and CFI_ENDPROC left defined in other archs > >>>> in spite of cfi annotations removal ages ago. For simplicity. I am using > >>>> DW_ prefix here. > >>> > >>> If objtool is going to be generating CFI instructions, why not have it > >>> generate .cfi_startproc and .cfi_endproc too? > >> > >> I tried that, but in many places it is very hard to recognize start > >> and/or end of a function. > > > > How so? objtool already knows where the start and end of every function > > is due to ENDPROC's use of the .type and .size macros. > > Right, I did not realized that we are writing about different things. So > yes, when the series is applied, we have ENTRY, ENDPROC et al. at all > appropriate places. We can indeed use that info. > > >> Having .cfi_startproc and .cfi_endproc in place makes it rather easy, > >> actually reduced to "emit dwarf instructions for this code between > >> here and there". Plus pre-prepared .eh_frame only to be extended. > >> (.eh_frame_hdr has to be rehashed of course.) > > > > Hm, but now objtool has to read *and* write CFI instead of just writing. > > That is needed due to inline assembly anyway :/. So the way I wanted to > go was: here you have code with possibly incomplete (but at least some) > CFIs, fix the broken ones. Otherwise we would have to differentiate 2 > kind of files: > * .c files with inline assembly (read-write = update CFIs) > * .S files with "native" assembly (write eh_frame header and also CFIs) Have you seen any real inline asm issues? I had been thinking they weren't a problem, because CFI instructions are only emitted for the function prologue and epilogue. Running objtool with CFI analysis seemed to confirm that -- I don't remember seeing any inline asm issues with CFI like we did with frame pointers. So my thinking for objtool CFI was: .c files: read-only .S files: write-only > > It would help to see the generation code. Have you written it? > > I started writing it and it is complete crap so far :P. Please see > "objtool: generate dwarf for asm" at: > https://git.kernel.org/cgit/linux/kernel/git/jirislaby/linux.git/log/?h=devel > > And yes, the current code is for .S files without any .eh_frame. Nice! Does it work? > Then I decided to clean up ENTRY/ENDPROC etc. first. It's up to > discussion what route we want to go, but I would prefer the > "read-write" since we have to implement it anyway. Yes, that would make sense if we have to do read-write for .c files. -- Josh