linux-m68k.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Helge Deller <deller@gmx.de>,
	Nick Desaulniers <ndesaulniers@google.com>,
	torvalds@linux-foundation.org, akpm@linux-foundation.org
Cc: "Nicolas Pitre" <nicolas.pitre@linaro.org>,
	linux-mips@linux-mips.org, linux-sh@vger.kernel.org,
	"Benjamin Herrenschmidt" <benh@kernel.crashing.org>,
	"Will Deacon" <will.deacon@arm.com>,
	"Paul Mackerras" <paulus@samba.org>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Vasily Gorbik" <gor@linux.vnet.ibm.com>,
	"Matt Turner" <mattst88@gmail.com>,
	uclinux-h8-devel@lists.sourceforge.jp,
	"Marc Zyngier" <marc.zyngier@arm.com>,
	"Ram Pai" <linuxram@us.ibm.com>,
	linux-um@lists.infradead.org,
	"Nicholas Piggin" <npiggin@gmail.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Shannon Nelson" <shannon.nelson@oracle.com>,
	tglx@linutronix.de, "Alex Bennée" <alex.bennee@linaro.org>,
	"Richard Henderson" <rth@twiddle.net>,
	"Jiri Kosina" <jkosina@suse.cz>,
	linux-kernel@vger.kerne
Subject: Re: [PATCH] treewide: remove current_text_addr
Date: Sat, 25 Aug 2018 19:38:47 -0700	[thread overview]
Message-ID: <c62e4e00-fb8f-19a6-f3eb-bde60118cb1a@zytor.com> (raw)
In-Reply-To: <207784db-4fcc-85e7-a0b2-fec26b7dab81@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 3032 bytes --]

On 08/25/18 03:48, Helge Deller wrote:
> 
> Currently alpha, s390, sparc, sh, c6x, ia64 and parisc provide an
> inline assembly function to get the current instruction pointer. 
> As mentioned in an earlier thread, I personally would *prefer* if 
> _THIS_IP_ would use those inline assembly instructions on those
> architectures instead of the (currently used) higher C-level
> implementation.
> 

Older ones have as well, e.g. x86.

The only reason to retain the use of an assembly function would be in
the case where either:

a) the C implementation produces bad or invalid code on certain
   architectures;
b) there is a specific requirement that either an absolute or a relative
   value is used in the binary, e.g. due to constraints on relocation.
   The latter particularly comes to mind since the x86-64 implementation
   in assembly will produce movq $.,%reg (which requires relocation)
   instead of the more natural leaq .(%rip),%reg.

In the case (a) those architectures ought to be able to simply

#undef _THIS_IP_
#define _THIS_IP_ blah...

and in case (b) *those specific instances* should be using some kind of
specially flagged function e.g. current_true_ip() vs.
current_linktime_ip() or somesuch.

I also note that a lot of those functions are not marked
__always_inline, which is a serious error should the compiler ever get
the idea to out-of-line these functions, which could potentially happen
as gcc is rather bad at assigning weight to an assembly statement.

I'm also going to throw in a perhaps ugly bomb into this discussion:

_THIS_IP_ seems to be horribly ill-defined; there is no kind of
serialization, and no reason to believe it can't be arbitrarily hoisted
inside a function. Furthermore, *most of the uses of _THIS_IP_ seem to
be either discarded or passed to a function*, and the location of a
function call, unlike _THIS_IP_ is very well defined.

In that case, the use of this mechanism is completely pointless and
ought to be replaced with _RET_IP_.  It seems like most invocations of
_THIS_IP_ can be trivially replaced with _RET_IP_ inside the function,
which would also reduce the footprint of the function call, for example:

__trace_puts() is only ever called with _THIS_IP_ as the first argument;
drop that argument and use _RET_IP_ inside the function (also,
__trace_puts() only ever uses strlen() as the third argument, which gcc
can of course optimize into a constant for the case of a consta t
string, but *is that optimization actually worth it*?  In the case of
__trace_puts(), a variable strlen() would only ever need to be called in
the case of an allocation actually happening -- otherwise str is never
examined -- and again, it increases the *code size* of the call site.
If it was worthwhile it would make more sense to at least force this
into the rodata section with the string, something like the attached
file for an example; however, I have a hunch it doesn't matter.

I wouldn't be surprised if all or nearly all instances of _THIS_IP_ can
be completely removed.

	-hpa

[-- Attachment #2: str.c --]
[-- Type: text/x-csrc, Size: 1231 bytes --]

#include <stddef.h>
#include <string.h>

#define _RET_IP_ ((unsigned long)__builtin_return_address(0))
#define no_inline __attribute__((noinline))
#define must_inline __attribute__((always_inline)) inline

struct myputs_string {
	size_t len;
	const char *str;
};

int _myputs_struct(const struct myputs_string * const strs);
int _myputs_string(const char *str);
int __myputs(unsigned long ip, const char *str, size_t len);

int no_inline _myputs_struct(const struct myputs_string * const strs)
{
	return __myputs(_RET_IP_, strs->str, strs->len);
}

int no_inline _myputs_string(const char *str)
{
	return __myputs(_RET_IP_, str, strlen(str)+1);
}

#define myputs(s)							\
({									\
	int _rv;							\
	if (__builtin_constant_p(s) &&					\
	    __builtin_constant_p(strlen(s)) &&				\
	    strlen(s)+1 == sizeof(s)) {					\
		static const struct myputs_string _mps = {		\
			.len = sizeof(s),				\
			.str = __builtin_constant_p(s) ? s : NULL,	\
		};							\
		_rv = _myputs_struct(&_mps);				\
	} else {							\
		_rv = _myputs_string(s);				\
	}								\
	_rv;								\
})

int test1(void);
int test2(const char *strx);

int test1(void)
{
	return myputs("Foobar");
}

int test2(const char *strx)
{
	return myputs(strx);
}

		

[-- Attachment #3: Type: text/plain, Size: 169 bytes --]

_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

       reply	other threads:[~2018-08-26  2:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAKwvOdkWL_2yTnJqM6n6R9UCPwY4iz-9BQYGN2MDAk9EzumUvA@mail.gmail.com>
     [not found] ` <20180821202900.208417-1-ndesaulniers@google.com>
     [not found]   ` <207784db-4fcc-85e7-a0b2-fec26b7dab81@gmx.de>
2018-08-26  2:38     ` H. Peter Anvin [this message]
2018-08-26  3:16       ` [PATCH] treewide: remove current_text_addr H. Peter Anvin
2018-08-26  4:56         ` H. Peter Anvin
2018-08-26 19:30           ` H. Peter Anvin
2018-08-26 20:25             ` Linus Torvalds
2018-08-27  2:52               ` Nick Desaulniers
2018-08-27  7:33                 ` Peter Zijlstra
2018-08-27 12:26                   ` H. Peter Anvin
2018-08-27 13:11                     ` Peter Zijlstra
2018-08-27 13:33                       ` H. Peter Anvin
2018-08-31 16:48                         ` Nick Desaulniers
2018-08-27  7:43               ` Nicholas Piggin
2018-08-26 23:20             ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c62e4e00-fb8f-19a6-f3eb-bde60118cb1a@zytor.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.bennee@linaro.org \
    --cc=benh@kernel.crashing.org \
    --cc=catalin.marinas@arm.com \
    --cc=deller@gmx.de \
    --cc=geert@linux-m68k.org \
    --cc=gor@linux.vnet.ibm.com \
    --cc=jejb@parisc-linux.org \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kerne \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linuxram@us.ibm.com \
    --cc=luto@kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mattst88@gmail.com \
    --cc=mpe@ellerman.id.au \
    --cc=ndesaulniers@google.com \
    --cc=nicolas.pitre@linaro.org \
    --cc=npiggin@gmail.com \
    --cc=paulus@samba.org \
    --cc=rth@twiddle.net \
    --cc=shannon.nelson@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=uclinux-h8-devel@lists.sourceforge.jp \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).