From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data Date: Tue, 7 Mar 2017 08:57:55 +0100 Message-ID: <20170307075755.GA29906@gmail.com> References: <20170217104757.28588-1-jslaby@suse.cz> <20170301093855.GA27152@gmail.com> <20170301102754.GA13374@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: hpa@zytor.com Cc: Juergen Gross , Len Brown , Andrew Morton , linux-pm@vger.kernel.org, Linus Torvalds , x86@kernel.org, "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, mingo@redhat.com, Pavel Machek , jpoimboe@redhat.com, xen-devel@lists.xenproject.org, Thomas Gleixner , Jiri Slaby , Boris Ostrovsky , Peter Zijlstra List-Id: linux-pm@vger.kernel.org CiogaHBhQHp5dG9yLmNvbSA8aHBhQHp5dG9yLmNvbT4gd3JvdGU6Cgo+IE9uIE1hcmNoIDEsIDIw MTcgMjoyNzo1NCBBTSBQU1QsIEluZ28gTW9sbmFyIDxtaW5nb0BrZXJuZWwub3JnPiB3cm90ZToK PiA+Cj4gPiogVGhvbWFzIEdsZWl4bmVyIDx0Z2x4QGxpbnV0cm9uaXguZGU+IHdyb3RlOgo+ID4K PiA+PiBPbiBXZWQsIDEgTWFyIDIwMTcsIEluZ28gTW9sbmFyIHdyb3RlOgo+ID4+ID4gCj4gPj4g PiAqIEppcmkgU2xhYnkgPGpzbGFieUBzdXNlLmN6PiB3cm90ZToKPiA+PiA+IAo+ID4+ID4gPiBU aGlzIGlzIGEgc3RhcnQgb2Ygc2VyaWVzIHRvIHVuaWZ5IHVzZSBvZiBFTlRSWSwgRU5EUFJPQywg R0xPQkFMLAo+ID5FTkQsCj4gPj4gPiA+IGFuZCBvdGhlciBtYWNyb3MgYWNyb3NzIHg4Ni4gV2hl biB3ZSBoYXZlIGFsbCB0aGlzIHNvcnRlZCBvdXQsCj4gPnRoaXMgd2lsbAo+ID4+ID4gPiBoZWxw IHRvIGluamVjdCBEV0FSRiB1bndpbmRpbmcgaW5mbyBieSBvYmp0b29sIGxhdGVyLgo+ID4+ID4g PiAKPiA+PiA+ID4gU28sIGxldCB1cyB1c2UgdGhlIG1hY3JvcyB0aGlzIHdheToKPiA+PiA+ID4g KiBFTlRSWSAtLSBzdGFydCBvZiBhIGdsb2JhbCBmdW5jdGlvbgo+ID4+ID4gPiAqIEVORFBST0Mg LS0gZW5kIG9mIGEgbG9jYWwvZ2xvYmFsIGZ1bmN0aW9uCj4gPj4gPiA+ICogR0xPQkFMIC0tIHN0 YXJ0IG9mIGEgZ2xvYmFsbHkgdmlzaWJsZSBkYXRhIHN5bWJvbAo+ID4+ID4gPiAqIEVORCAtLSBl bmQgb2YgbG9jYWwvZ2xvYmFsIGRhdGEgc3ltYm9sCj4gPj4gPiAKPiA+PiA+IFNvIGhvdyBhYm91 dCB1c2luZyBtYWNybyBuYW1lcyB0aGF0IGFjdHVhbGx5IHNob3cgdGhlIHB1cnBvc2UsCj4gPmlu c3RlYWQgb2YgCj4gPj4gPiBpbXBvcnRpbmcgYWxsIHRoZSBjcmFwcHksIGhpc3RvcmljLCBlc3Nl bnRpYWxseSByYW5kb21seSBjaG9zZW4KPiA+ZGVidWcgc3ltYm9sIG1hY3JvIAo+ID4+ID4gbmFt ZXMgZnJvbSB0aGUgYmludXRpbHMgYW5kIG9sZGVyIGtlcm5lbHM/Cj4gPj4gPiAKPiA+PiA+IFNv bWV0aGluZyBzYW5lLCBsaWtlOgo+ID4+ID4gCj4gPj4gPiAJU1lNX19GVU5DVElPTl9TVEFSVAo+ ID4+IAo+ID4+IFNhbmUgd291bGQgYmU6Cj4gPj4gCj4gPj4gICAgICAJU1lNX0ZVTkNUSU9OX1NU QVJUCj4gPj4gCj4gPj4gVGhlIGRvdWJsZSB1bmRlcnNjb3JlIGlzIGp1c3Qgbm90IGdpdmluZyBh bnkgdmFsdWUuCj4gPgo+ID5TbyB0aGUgZG91YmxlIHVuZGVyc2NvcmUgKGF0IGxlYXN0IGluIG15 IHZpZXcpIGhhcyB0d28gYWR2YW50YWdlczoKPiA+Cj4gPjEpIGl0IGhlbHBzIHNlcGFyYXRlIHRo ZSBwcmVmaXggZnJvbSB0aGUgcG9zdGZpeC4KPiA+Cj4gPkkuZS4gaXQncyBhICdzeW1ib2xzJyBu YW1lc3BhY2UsIGFuZCBhICdmdW5jdGlvbiBzdGFydCcsIG5vdCB0aGUKPiA+J3N0YXJ0JyBvZiBh IAo+ID4nc3ltYm9sIGZ1bmN0aW9uJy4KPiA+Cj4gPjIpIEl0IGFsc28gaGVscHMgZWFzeSBncmVw cGFiaWxpdHkuCj4gPgo+ID5UcnkgdGhpcyBpbiBsYXRlc3QgLXRpcDoKPiA+Cj4gPiAgZ2l0IGdy ZXAgZTgyMF9fCj4gPgo+ID5UbyBzZWUgYWxsIHRoZSBFODIwIEFQSSBjYWxscyAtIHdpdGggbm8g ZmFsc2UgcG9zaXRpdmVzIQo+ID4KPiA+J2dpdCBncmVwIGU4MjBfJyBvbiB0aGUgb3RoZXIgaGFu ZCBpcyBhIGxvdCBsZXNzIHJlbGlhYmxlLi4uCj4gPgo+ID5CdXQgbm8gc3Ryb25nIGZlZWxpbmdz IGVpdGhlciB3YXksIEkganVzdCB0cnkgdG8gc25lYWsgaW4gdGhlc2Ugc21hbGwKPiA+bmFtZXNw YWNlIAo+ID5zdHJ1Y3R1cmUgdHJpY2tzIHdoZW4gbm9ib2R5J3MgbG9va2luZyEgOy0pCj4gPgo+ ID5UaGFua3MsCj4gPgo+ID4JSW5nbwo+IAo+IFRoaXMgc2VlbXMgbmVlZGxlc3NseSB2ZXJib3Nl IHRvIG1lIGFuZCBjbHV0dGVycyB0aGUgY29kZS4KPiAKPiBIb3cgYWJvdXQ6Cj4gCj4gUFJPQy4u RU5EUFJPQywgTE9DQUxQUk9DLi5FTkRQUk9DIGFuZCBEQVRBLi5FTkREQVRBLiAgQ2xlYXIsIHVu YW1iaWd1b3VzIGFuZCBiYWxhbmNlZC4KCkknbSBzb3JyeSwgYnV0IHRoYXQgbmFtaW5nIHNjaGVt ZSBpcyBkaXNndXNpbmcsIGl0IHJlbWluZHMgbWUgb2YgQkFTSUMgCm5vbWVuY2xhdHVyZSAuLi4g ZGlkIHdlIHJ1biBvdXQgb2YgdW5kZXJzY29yZXMgb3Igd2hhdD8KCk5vciB3b3VsZCBjbGVhcmx5 IHN0cnVjdHVyZWQgbmFtZXMgY2x1dHRlciBhbnl0aGluZywgdGhpcyBpc24ndCBnb2luZyB0byBi ZSB1c2VkIApkZWVwIGluc2lkZSBuZXN0ZWQgY29kZSwgaXQncyBnb2luZyB0byBiZSB0aGUgc2lu Z2xlIGxldmVsIHN5bnRhY3RpYyB0ZXJtIGluIAphZGRpdGlvbiB0byB0aGUgc3ltYm9sIG5hbWUg aXRzZWxmOgoKCVNZTV9fRlVOQ1RJT05fU1RBUlQoc29tZV9rZXJuZWxfYXNtX2Z1bmN0aW9uKQoJ Li4uCglTWU1fX0ZVTkNUSU9OX0VORChzb21lX2tlcm5lbF9hc21fZnVuY3Rpb24pCgpXZSBjb3Vs ZCBzaG9ydGVuIGl0IHRvICdGVU5DJyBpZiBsZW5ndGggaXMgcmVhbGx5IGFuIGlzc3VlOgoKCVNZ TV9fRlVOQ19TVEFSVChzb21lX2tlcm5lbF9hc21fZnVuY3Rpb24pCgkuLi4KCVNZTV9fRlVOQ19F TkQoc29tZV9rZXJuZWxfYXNtX2Z1bmN0aW9uKQoKQWxzbywgJ1BST0MnLCBwcmVzdW1hYmx5IHN0 YW5kaW5nIGZvciAncHJvY2VkdXJlJywgaXMgYm90aCBhbWJpZ3VvdXMgYW5kIGEgCm1pc25vbWVy OgoKIC0gaXQncyBhbWJpZ3VvdXMgd2l0aCBjb21tb25seSB1c2VkIGFiYnJldmlhdGlvbnMgb2Yg cHJvY2ZzIGFuZCBwcm9jZXNzCgogLSBDIGZ1bmN0aW9ucyBhcmUgbm90IGFjdHVhbGx5ICdwcm9j ZWR1cmVzJy4gUHJvY2VkdXJlcyBpbiBQQVNDQUwgc3R5bGUgbGFuZ3VhZ2VzCiAgIGRlbm90ZSBm dW5jdGlvbnMgdGhhdCBkb24ndCByZXR1cm4gYW55IHZhbHVlcy4gTW9zdCBvZiB0aGUga2VybmVs IGFzbSBmdW5jdGlvbnMKICAgYWN0dWFsbHkgZG8uIEkgcmVhbGl6ZSB0aGF0IGV2ZW4gaW4gQyB3 ZSBzb21ldGltZXMgdGFsayBhYm91dCAncHJvY2VkdXJlcycgb3V0CiAgIG9mIGh5c3RlcmljYWwg aW5lcnRpYSwgYnV0IGlmIHlvdSBjaGVjayB0aGUgQyBzdGFuZGFyZHMsIG1vc3Qgb2YgdGhlbSBk b24ndAogICBldmVuIHVzZSB0aGUgdGVybSAncHJvY2VkdXJlJy4KCidmdW5jdGlvbicgb24gdGhl IG90aGVyIGhhbmQgaXMgdG90YWxseSB1bmFtYmlndW91cy4KClBsdXMgdGhlIGxhY2sgb2YgU1RB UlQvU1RPUCAob3IgQkVHSU4vRU5EKSBtYWtlcyBpdCBlYXN5IHRvIGNvbW1pdCB0aGUgbWlzdGFr ZSBvZiAKZm9yZ2V0dGluZyB0byBhZGQgdGhlIGVuZCBtYXJrZXIsIGFuZCB5b3VyIG5hbWluZyBz Y2hlbWUgcHJlc2VydmVzIHRoYXQhCgpTbyBpZiB3ZSBmaXgvZXh0ZW5kIHRoZXNlIG1hY3JvcyB0 aGVuIF9QTEVBU0VfIHdlIG5lZWQgdG8gZ2V0IHRoaXMgc3R1cGlkLCAKaWxsb2dpY2FsLCBub25z ZW5zaWNhbCwgZXh0ZXJuYWwgdG9vbGluZyBpbmhlcml0ZWQgbmFtaW5nIGNyYXppbmVzcyBmaXhl ZCBmaXJzdCwgCm5vdCBkb3VibGVkIGRvd24gb24uLi4KCjwvcmFudD4KClRoYW5rcywKCglJbmdv CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpYZW4tZGV2 ZWwgbWFpbGluZyBsaXN0Clhlbi1kZXZlbEBsaXN0cy54ZW4ub3JnCmh0dHBzOi8vbGlzdHMueGVu Lm9yZy94ZW4tZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754914AbdCGIAZ (ORCPT ); Tue, 7 Mar 2017 03:00:25 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34788 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751838AbdCGH6k (ORCPT ); Tue, 7 Mar 2017 02:58:40 -0500 Date: Tue, 7 Mar 2017 08:57:55 +0100 From: Ingo Molnar To: hpa@zytor.com Cc: Thomas Gleixner , Jiri Slaby , mingo@redhat.com, x86@kernel.org, jpoimboe@redhat.com, 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, Linus Torvalds , Andrew Morton , Peter Zijlstra Subject: Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data Message-ID: <20170307075755.GA29906@gmail.com> References: <20170217104757.28588-1-jslaby@suse.cz> <20170301093855.GA27152@gmail.com> <20170301102754.GA13374@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * hpa@zytor.com wrote: > On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote: > > > >* Thomas Gleixner wrote: > > > >> On Wed, 1 Mar 2017, Ingo Molnar wrote: > >> > > >> > * Jiri Slaby wrote: > >> > > >> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, > >END, > >> > > and other macros across x86. When we have all this sorted out, > >this will > >> > > help to inject DWARF unwinding info by objtool later. > >> > > > >> > > So, let us use the macros this way: > >> > > * ENTRY -- start of a global function > >> > > * ENDPROC -- end of a local/global function > >> > > * GLOBAL -- start of a globally visible data symbol > >> > > * END -- end of local/global data symbol > >> > > >> > So how about using macro names that actually show the purpose, > >instead of > >> > importing all the crappy, historic, essentially randomly chosen > >debug symbol macro > >> > names from the binutils and older kernels? > >> > > >> > Something sane, like: > >> > > >> > SYM__FUNCTION_START > >> > >> Sane would be: > >> > >> SYM_FUNCTION_START > >> > >> The double underscore is just not giving any value. > > > >So the double underscore (at least in my view) has two advantages: > > > >1) it helps separate the prefix from the postfix. > > > >I.e. it's a 'symbols' namespace, and a 'function start', not the > >'start' of a > >'symbol function'. > > > >2) It also helps easy greppability. > > > >Try this in latest -tip: > > > > git grep e820__ > > > >To see all the E820 API calls - with no false positives! > > > >'git grep e820_' on the other hand is a lot less reliable... > > > >But no strong feelings either way, I just try to sneak in these small > >namespace > >structure tricks when nobody's looking! ;-) > > > >Thanks, > > > > Ingo > > This seems needlessly verbose to me and clutters the code. > > How about: > > PROC..ENDPROC, LOCALPROC..ENDPROC and DATA..ENDDATA. Clear, unambiguous and balanced. I'm sorry, but that naming scheme is disgusing, it reminds me of BASIC nomenclature ... did we run out of underscores or what? Nor would clearly structured names clutter anything, this isn't going to be used deep inside nested code, it's going to be the single level syntactic term in addition to the symbol name itself: SYM__FUNCTION_START(some_kernel_asm_function) ... SYM__FUNCTION_END(some_kernel_asm_function) We could shorten it to 'FUNC' if length is really an issue: SYM__FUNC_START(some_kernel_asm_function) ... SYM__FUNC_END(some_kernel_asm_function) Also, 'PROC', presumably standing for 'procedure', is both ambiguous and a misnomer: - it's ambiguous with commonly used abbreviations of procfs and process - C functions are not actually 'procedures'. Procedures in PASCAL style languages denote functions that don't return any values. Most of the kernel asm functions actually do. I realize that even in C we sometimes talk about 'procedures' out of hysterical inertia, but if you check the C standards, most of them don't even use the term 'procedure'. 'function' on the other hand is totally unambiguous. Plus the lack of START/STOP (or BEGIN/END) makes it easy to commit the mistake of forgetting to add the end marker, and your naming scheme preserves that! So if we fix/extend these macros then _PLEASE_ we need to get this stupid, illogical, nonsensical, external tooling inherited naming craziness fixed first, not doubled down on... Thanks, Ingo