From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934237AbdBQO0l (ORCPT ); Fri, 17 Feb 2017 09:26:41 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:35630 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934082AbdBQO0k (ORCPT ); Fri, 17 Feb 2017 09:26:40 -0500 Subject: Re: [PREVIEW 10/10] linkage: add .cfi_{start/end}proc to ENTRY/ENDPROC To: Josh Poimboeuf References: <20170217104757.28588-1-jslaby@suse.cz> <20170217104757.28588-10-jslaby@suse.cz> <20170217131602.pxrgfaeaanrzymnv@treble> <20170217140717.sxvt7tkvsez2pl7e@treble> Cc: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org, linux-kernel@vger.kernel.org From: Jiri Slaby Message-ID: <7f613a09-39f8-5477-ed5e-17024baf5876@suse.cz> Date: Fri, 17 Feb 2017 15:26:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170217140717.sxvt7tkvsez2pl7e@treble> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) > 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. 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. thanks, -- js suse labs