All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Feng Tang <feng.tang@intel.com>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	lkp <lkp@intel.com>,
	"kbuild-all@lists.01.org" <kbuild-all@lists.01.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: {standard input}:577: Error: unsupported relocation against base
Date: Wed, 17 Feb 2021 09:37:04 -0600	[thread overview]
Message-ID: <20210217153704.GM28121@gate.crashing.org> (raw)
In-Reply-To: <87a6s3uu3y.fsf@mpe.ellerman.id.au>

Hi!

On Wed, Feb 17, 2021 at 04:43:45PM +1100, Michael Ellerman wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Tue, Feb 16, 2021 at 08:36:02PM +1100, Michael Ellerman wrote:
> >> Feng Tang <feng.tang@intel.com> writes:
> >> >   {standard input}:577: Error: unsupported relocation against base
> >> >   {standard input}:580: Error: unsupported relocation against base
> >> >   {standard input}:583: Error: unsupported relocation against base
> >
> >> > The reason is macro 'mfdcr' requirs an instant number as parameter,
> >> > which is not met by show_plbopb_regs().
> >> 
> >> It doesn't require a constant, it checks if the argument is constant:
> >> 
> >> #define mfdcr(rn)						\
> >> 	({unsigned int rval;					\
> >> 	if (__builtin_constant_p(rn) && rn < 1024)		\
> >> 		asm volatile("mfdcr %0," __stringify(rn)	\
> >> 		              : "=r" (rval));			\
> >> 	else if (likely(cpu_has_feature(CPU_FTR_INDEXED_DCR)))	\
> >> 		rval = mfdcrx(rn);				\
> >> 	else							\
> >> 		rval = __mfdcr(rn);				\
> >> 	rval;})
> >
> > It requires a constant number with known (at compile time) value, while
> > __builtin_constant_p checks for any constant.  The address of some
> > defined symbol is a constant as well normally, for example.
> >
> > It's better to write that asm as
> > 	asm volatile("mfdcr %0,%1" : "=r" (rval) : "n"(rn));
> > btw (the "n" constraint means "constant integer with known value" (it
> > stands for "numeric"), while the "i" constraint means just "constant
> > integer").
> 
> Actually that fixes it.

Huh interesting.  I was going to suggest to use __is_constexpr instead,
but that should return true for slightly fewer expressions (but probably
still okay in this case).

> diff --git a/arch/powerpc/include/asm/dcr-native.h b/arch/powerpc/include/asm/dcr-native.h
> index 7141ccea8c94..d143308b0f95 100644
> --- a/arch/powerpc/include/asm/dcr-native.h
> +++ b/arch/powerpc/include/asm/dcr-native.h
> @@ -53,8 +53,8 @@ static inline void mtdcrx(unsigned int reg, unsigned int val)
>  #define mfdcr(rn)                                              \
>         ({unsigned int rval;                                    \
>         if (__builtin_constant_p(rn) && rn < 1024)              \
> -               asm volatile("mfdcr %0," __stringify(rn)        \
> -                             : "=r" (rval));                   \
> +               asm volatile("mfdcr %0, %1" : "=r" (rval)       \
> +                            : "n" (rn));                       \
>         else if (likely(cpu_has_feature(CPU_FTR_INDEXED_DCR)))  \
>                 rval = mfdcrx(rn);                              \
>         else                                                    \
> 
> 
> I guess because we give the compiler time to work out the constant,
> rather than stringifying it immediately.

Yeah, this is not preprocessor magic, the compiler actually does its
thing here.  It still won't work if the compiler cannot reduce the
expression to a number (but it does see it is constant), but that is the
best you can do here probably.


Segher

  reply	other threads:[~2021-02-17 15:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-05 10:58 {standard input}:577: Error: unsupported relocation against base kernel test robot
2021-01-05 10:58 ` kernel test robot
2021-01-18 14:24 ` Christophe Leroy
2021-02-05 10:08   ` Feng Tang
2021-02-05 10:08     ` Feng Tang
2021-02-16  9:36     ` Michael Ellerman
2021-02-16  9:36       ` Michael Ellerman
2021-02-16 22:06       ` Segher Boessenkool
2021-02-17  5:43         ` Michael Ellerman
2021-02-17  5:43           ` Michael Ellerman
2021-02-17 15:37           ` Segher Boessenkool [this message]
2021-02-17 10:49       ` Feng Tang
2021-02-17 10:49         ` Feng Tang
2021-02-18 11:08         ` Michael Ellerman
2021-02-18 11:08           ` Michael Ellerman

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=20210217153704.GM28121@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=feng.tang@intel.com \
    --cc=kbuild-all@lists.01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=mpe@ellerman.id.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.