From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934180AbdBQOHV (ORCPT ); Fri, 17 Feb 2017 09:07:21 -0500 Received: from mx1.redhat.com ([209.132.183.28]:45348 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933951AbdBQOHU (ORCPT ); Fri, 17 Feb 2017 09:07:20 -0500 Date: Fri, 17 Feb 2017 08:07:17 -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: <20170217140717.sxvt7tkvsez2pl7e@treble> References: <20170217104757.28588-1-jslaby@suse.cz> <20170217104757.28588-10-jslaby@suse.cz> <20170217131602.pxrgfaeaanrzymnv@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.26]); Fri, 17 Feb 2017 14:07:20 +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 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. > 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. It would help to see the generation code. Have you written it? -- Josh