Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753006AbdCTPl0 (ORCPT <rfc822;w@1wt.eu>);
        Mon, 20 Mar 2017 11:41:26 -0400
Received: from mail-wm0-f67.google.com ([74.125.82.67]:33564 "EHLO
        mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1754968AbdCTPjq (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 20 Mar 2017 11:39:46 -0400
Subject: Re: [PATCH v2 02/10] x86: assembly, FUNC_START for fn, DATA_START for
 data
To: Josh Poimboeuf <jpoimboe@redhat.com>
References: <9ea5e137-61f9-dccc-bb9d-ac3ff86e5867@suse.cz>
 <20170320123222.15453-1-jslaby@suse.cz>
 <20170320123222.15453-2-jslaby@suse.cz>
 <20170320133243.5rvae6liwwqg4dve@treble>
Cc: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com, x86@kernel.org,
        linux-kernel@vger.kernel.org,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Juergen Gross <jgross@suse.com>, xen-devel@lists.xenproject.org,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
        linux-pm@vger.kernel.org
From: Jiri Slaby <jslaby@suse.cz>
Message-ID: <cf9b5094-a7b0-76ae-714a-7e4c8a0f79fb@suse.cz>
Date: Mon, 20 Mar 2017 16:32:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <20170320133243.5rvae6liwwqg4dve@treble>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1655
Lines: 46

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:
<code>
.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.

> 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.

thanks,
-- 
js
suse labs