* Re: {standard input}:577: Error: unsupported relocation against base
@ 2021-02-16 9:36 ` Michael Ellerman
0 siblings, 0 replies; 15+ messages in thread
From: Michael Ellerman @ 2021-02-16 9:36 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 2449 bytes --]
Feng Tang <feng.tang@intel.com> writes:
> Hi Christophe and Michael,
>
> On Mon, Jan 18, 2021 at 10:24:08PM +0800, Christophe Leroy wrote:
>>
>> Le 05/01/2021 ? 11:58, kernel test robot a 閏rit :
>> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> > head: e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
>> > commit: 8b8319b181fd9d6821703fef1228b4dcde613a16 powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
>>
>> I see no link with that commit. Looks like the problem has been existing for some time.
>> It exists on the commit before that one, it exists on v5.9 and it exists on v5.10 with that commit
>> reverted.
>
> Yes, this seems to be a long-standing issue, and we just double checked
> this compile error.
>
> It happend when compiling arch/powerpc/platforms/44x/fsp2.c, macro
> 'mfdcr' requirs an instant number as parameter, while is not met by
> show_plbopb_regs(). Changing show_plbopb_regs() from function to
> a macro fixes the error, as the patch below:
>
> Thanks,
> Feng
>
>
> From 3bcb9638afc873d0e803aea1aad4f77bf1c2f6f6 Mon Sep 17 00:00:00 2001
> From: Feng Tang <feng.tang@intel.com>
> Date: Fri, 5 Feb 2021 16:08:43 +0800
> Subject: [PATCH] powerpc/44x/fsp2: fix a compiling error regarding macro
> 'mdfcr'
>
> 0day's kbuild test found error:
>
> "
> CC arch/powerpc/platforms/44x/fsp2.o
>
> {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;})
But the error you're seeing implies the compiler is choosing the first
leg of the if, even when rn == "base + x", which is surprising.
We've had cases in the past of __builtin_constant_p() returning false
for things that a human can see are constant@build time, but I've
never seen the reverse.
cheers
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: {standard input}:577: Error: unsupported relocation against base
2021-02-16 9:36 ` Michael Ellerman
(?)
@ 2021-02-16 22:06 ` Segher Boessenkool
2021-02-17 5:43 ` Michael Ellerman
-1 siblings, 1 reply; 15+ messages in thread
From: Segher Boessenkool @ 2021-02-16 22:06 UTC (permalink / raw)
To: Michael Ellerman
Cc: Feng Tang, Christophe Leroy, lkp, kbuild-all, linux-kernel
Hi!
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").
> But the error you're seeing implies the compiler is choosing the first
> leg of the if, even when rn == "base + x", which is surprising.
>
> We've had cases in the past of __builtin_constant_p() returning false
> for things that a human can see are constant at build time, but I've
> never seen the reverse.
And it doesn't here :-)
But, you need some way to figure out an arg is a constant known number
here. We don't have a builtin for that I think. Maybe some trick can
be done? Maybe simply test "rn >= 0" as well, does that work?
Segher
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: {standard input}:577: Error: unsupported relocation against base
2021-02-16 22:06 ` Segher Boessenkool
@ 2021-02-17 5:43 ` Michael Ellerman
0 siblings, 0 replies; 15+ messages in thread
From: Michael Ellerman @ 2021-02-17 5:43 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Feng Tang, Christophe Leroy, lkp, kbuild-all, linux-kernel
Segher Boessenkool <segher@kernel.crashing.org> writes:
> Hi!
>
> 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.
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.
cheers
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: {standard input}:577: Error: unsupported relocation against base
@ 2021-02-17 5:43 ` Michael Ellerman
0 siblings, 0 replies; 15+ messages in thread
From: Michael Ellerman @ 2021-02-17 5:43 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 2553 bytes --]
Segher Boessenkool <segher@kernel.crashing.org> writes:
> Hi!
>
> 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.
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.
cheers
^ permalink raw reply related [flat|nested] 15+ messages in thread* Re: {standard input}:577: Error: unsupported relocation against base
2021-02-17 5:43 ` Michael Ellerman
(?)
@ 2021-02-17 15:37 ` Segher Boessenkool
-1 siblings, 0 replies; 15+ messages in thread
From: Segher Boessenkool @ 2021-02-17 15:37 UTC (permalink / raw)
To: Michael Ellerman
Cc: Feng Tang, Christophe Leroy, lkp, kbuild-all, linux-kernel
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: {standard input}:577: Error: unsupported relocation against base
2021-02-16 9:36 ` Michael Ellerman
@ 2021-02-17 10:49 ` Feng Tang
-1 siblings, 0 replies; 15+ messages in thread
From: Feng Tang @ 2021-02-17 10:49 UTC (permalink / raw)
To: Michael Ellerman
Cc: Christophe Leroy, lkp, kbuild-all, linux-kernel, Segher Boessenkool
Hi Michael,
On Tue, Feb 16, 2021 at 08:36:02PM +1100, Michael Ellerman wrote:
> Feng Tang <feng.tang@intel.com> writes:
> > Hi Christophe and Michael,
> >
> > On Mon, Jan 18, 2021 at 10:24:08PM +0800, Christophe Leroy wrote:
> >>
> >> Le 05/01/2021 ? 11:58, kernel test robot a 閏rit :
> >> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >> > head: e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
> >> > commit: 8b8319b181fd9d6821703fef1228b4dcde613a16 powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
> >>
> >> I see no link with that commit. Looks like the problem has been existing for some time.
> >> It exists on the commit before that one, it exists on v5.9 and it exists on v5.10 with that commit
> >> reverted.
> >
> > Yes, this seems to be a long-standing issue, and we just double checked
> > this compile error.
> >
> > It happend when compiling arch/powerpc/platforms/44x/fsp2.c, macro
> > 'mfdcr' requirs an instant number as parameter, while is not met by
> > show_plbopb_regs(). Changing show_plbopb_regs() from function to
> > a macro fixes the error, as the patch below:
> >
> > Thanks,
> > Feng
> >
> >
> > From 3bcb9638afc873d0e803aea1aad4f77bf1c2f6f6 Mon Sep 17 00:00:00 2001
> > From: Feng Tang <feng.tang@intel.com>
> > Date: Fri, 5 Feb 2021 16:08:43 +0800
> > Subject: [PATCH] powerpc/44x/fsp2: fix a compiling error regarding macro
> > 'mdfcr'
> >
> > 0day's kbuild test found error:
> >
> > "
> > CC arch/powerpc/platforms/44x/fsp2.o
> >
> > {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:
Aha, seems my grep found the wrong target: arch/powerpc/boot/dcr.h,
which has
#define mfdcr(rn) \
({ \
unsigned long rval; \
asm volatile("mfdcr %0,%1" : "=r"(rval) : "i"(rn)); \
rval; \
})
> #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;})
>
> But the error you're seeing implies the compiler is choosing the first
> leg of the if, even when rn == "base + x", which is surprising.
Yes, it might be related to compiler (though myself isn't faimiliar
with it). As show_plbopb_regs() was introduced by commit 7813043e1bbc
("powerpc/44x/fsp2: Add irq error handlers") back in 2017, while it
was just reported.
> We've had cases in the past of __builtin_constant_p() returning false
> for things that a human can see are constant at build time, but I've
> never seen the reverse.
>
> cheers
Thanks,
Feng
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: {standard input}:577: Error: unsupported relocation against base
@ 2021-02-17 10:49 ` Feng Tang
0 siblings, 0 replies; 15+ messages in thread
From: Feng Tang @ 2021-02-17 10:49 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]
Hi Michael,
On Tue, Feb 16, 2021 at 08:36:02PM +1100, Michael Ellerman wrote:
> Feng Tang <feng.tang@intel.com> writes:
> > Hi Christophe and Michael,
> >
> > On Mon, Jan 18, 2021 at 10:24:08PM +0800, Christophe Leroy wrote:
> >>
> >> Le 05/01/2021 ? 11:58, kernel test robot a 閏rit :
> >> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >> > head: e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
> >> > commit: 8b8319b181fd9d6821703fef1228b4dcde613a16 powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
> >>
> >> I see no link with that commit. Looks like the problem has been existing for some time.
> >> It exists on the commit before that one, it exists on v5.9 and it exists on v5.10 with that commit
> >> reverted.
> >
> > Yes, this seems to be a long-standing issue, and we just double checked
> > this compile error.
> >
> > It happend when compiling arch/powerpc/platforms/44x/fsp2.c, macro
> > 'mfdcr' requirs an instant number as parameter, while is not met by
> > show_plbopb_regs(). Changing show_plbopb_regs() from function to
> > a macro fixes the error, as the patch below:
> >
> > Thanks,
> > Feng
> >
> >
> > From 3bcb9638afc873d0e803aea1aad4f77bf1c2f6f6 Mon Sep 17 00:00:00 2001
> > From: Feng Tang <feng.tang@intel.com>
> > Date: Fri, 5 Feb 2021 16:08:43 +0800
> > Subject: [PATCH] powerpc/44x/fsp2: fix a compiling error regarding macro
> > 'mdfcr'
> >
> > 0day's kbuild test found error:
> >
> > "
> > CC arch/powerpc/platforms/44x/fsp2.o
> >
> > {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:
Aha, seems my grep found the wrong target: arch/powerpc/boot/dcr.h,
which has
#define mfdcr(rn) \
({ \
unsigned long rval; \
asm volatile("mfdcr %0,%1" : "=r"(rval) : "i"(rn)); \
rval; \
})
> #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;})
>
> But the error you're seeing implies the compiler is choosing the first
> leg of the if, even when rn == "base + x", which is surprising.
Yes, it might be related to compiler (though myself isn't faimiliar
with it). As show_plbopb_regs() was introduced by commit 7813043e1bbc
("powerpc/44x/fsp2: Add irq error handlers") back in 2017, while it
was just reported.
> We've had cases in the past of __builtin_constant_p() returning false
> for things that a human can see are constant at build time, but I've
> never seen the reverse.
>
> cheers
Thanks,
Feng
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: {standard input}:577: Error: unsupported relocation against base
2021-02-17 10:49 ` Feng Tang
@ 2021-02-18 11:08 ` Michael Ellerman
-1 siblings, 0 replies; 15+ messages in thread
From: Michael Ellerman @ 2021-02-18 11:08 UTC (permalink / raw)
To: Feng Tang
Cc: Christophe Leroy, lkp, kbuild-all, linux-kernel, Segher Boessenkool
Feng Tang <feng.tang@intel.com> writes:
> Hi Michael,
>
> On Tue, Feb 16, 2021 at 08:36:02PM +1100, Michael Ellerman wrote:
>> Feng Tang <feng.tang@intel.com> writes:
>> > Hi Christophe and Michael,
>> >
>> > On Mon, Jan 18, 2021 at 10:24:08PM +0800, Christophe Leroy wrote:
>> >>
>> >> Le 05/01/2021 ? 11:58, kernel test robot a 閏rit :
>> >> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> >> > head: e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
>> >> > commit: 8b8319b181fd9d6821703fef1228b4dcde613a16 powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
>> >>
>> >> I see no link with that commit. Looks like the problem has been existing for some time.
>> >> It exists on the commit before that one, it exists on v5.9 and it exists on v5.10 with that commit
>> >> reverted.
>> >
>> > Yes, this seems to be a long-standing issue, and we just double checked
>> > this compile error.
>> >
>> > It happend when compiling arch/powerpc/platforms/44x/fsp2.c, macro
>> > 'mfdcr' requirs an instant number as parameter, while is not met by
>> > show_plbopb_regs(). Changing show_plbopb_regs() from function to
>> > a macro fixes the error, as the patch below:
>> >
>> > Thanks,
>> > Feng
>> >
>> >
>> > From 3bcb9638afc873d0e803aea1aad4f77bf1c2f6f6 Mon Sep 17 00:00:00 2001
>> > From: Feng Tang <feng.tang@intel.com>
>> > Date: Fri, 5 Feb 2021 16:08:43 +0800
>> > Subject: [PATCH] powerpc/44x/fsp2: fix a compiling error regarding macro
>> > 'mdfcr'
>> >
>> > 0day's kbuild test found error:
>> >
>> > "
>> > CC arch/powerpc/platforms/44x/fsp2.o
>> >
>> > {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:
>
> Aha, seems my grep found the wrong target: arch/powerpc/boot/dcr.h,
> which has
>
> #define mfdcr(rn) \
> ({ \
> unsigned long rval; \
> asm volatile("mfdcr %0,%1" : "=r"(rval) : "i"(rn)); \
> rval; \
> })
Yeah, annoyingly we have several macros like that duplicated in
arch/powerpc/boot.
>> #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;})
>>
>> But the error you're seeing implies the compiler is choosing the first
>> leg of the if, even when rn == "base + x", which is surprising.
>
> Yes, it might be related to compiler (though myself isn't faimiliar
> with it). As show_plbopb_regs() was introduced by commit 7813043e1bbc
> ("powerpc/44x/fsp2: Add irq error handlers") back in 2017, while it
> was just reported.
It seems to be something in the config, I can only reproduce with the
config attached to the original report. I can't see any reason why the
config matters for this bug, but perhaps it's enabling something that's
confusing the compiler somehow.
Anyway I'll post a patch to change the asm so the bug goes away.
cheers
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: {standard input}:577: Error: unsupported relocation against base
@ 2021-02-18 11:08 ` Michael Ellerman
0 siblings, 0 replies; 15+ messages in thread
From: Michael Ellerman @ 2021-02-18 11:08 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]
Feng Tang <feng.tang@intel.com> writes:
> Hi Michael,
>
> On Tue, Feb 16, 2021 at 08:36:02PM +1100, Michael Ellerman wrote:
>> Feng Tang <feng.tang@intel.com> writes:
>> > Hi Christophe and Michael,
>> >
>> > On Mon, Jan 18, 2021 at 10:24:08PM +0800, Christophe Leroy wrote:
>> >>
>> >> Le 05/01/2021 ? 11:58, kernel test robot a 閏rit :
>> >> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>> >> > head: e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62
>> >> > commit: 8b8319b181fd9d6821703fef1228b4dcde613a16 powerpc/44x: Don't support 440 when CONFIG_PPC_47x is set
>> >>
>> >> I see no link with that commit. Looks like the problem has been existing for some time.
>> >> It exists on the commit before that one, it exists on v5.9 and it exists on v5.10 with that commit
>> >> reverted.
>> >
>> > Yes, this seems to be a long-standing issue, and we just double checked
>> > this compile error.
>> >
>> > It happend when compiling arch/powerpc/platforms/44x/fsp2.c, macro
>> > 'mfdcr' requirs an instant number as parameter, while is not met by
>> > show_plbopb_regs(). Changing show_plbopb_regs() from function to
>> > a macro fixes the error, as the patch below:
>> >
>> > Thanks,
>> > Feng
>> >
>> >
>> > From 3bcb9638afc873d0e803aea1aad4f77bf1c2f6f6 Mon Sep 17 00:00:00 2001
>> > From: Feng Tang <feng.tang@intel.com>
>> > Date: Fri, 5 Feb 2021 16:08:43 +0800
>> > Subject: [PATCH] powerpc/44x/fsp2: fix a compiling error regarding macro
>> > 'mdfcr'
>> >
>> > 0day's kbuild test found error:
>> >
>> > "
>> > CC arch/powerpc/platforms/44x/fsp2.o
>> >
>> > {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:
>
> Aha, seems my grep found the wrong target: arch/powerpc/boot/dcr.h,
> which has
>
> #define mfdcr(rn) \
> ({ \
> unsigned long rval; \
> asm volatile("mfdcr %0,%1" : "=r"(rval) : "i"(rn)); \
> rval; \
> })
Yeah, annoyingly we have several macros like that duplicated in
arch/powerpc/boot.
>> #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;})
>>
>> But the error you're seeing implies the compiler is choosing the first
>> leg of the if, even when rn == "base + x", which is surprising.
>
> Yes, it might be related to compiler (though myself isn't faimiliar
> with it). As show_plbopb_regs() was introduced by commit 7813043e1bbc
> ("powerpc/44x/fsp2: Add irq error handlers") back in 2017, while it
> was just reported.
It seems to be something in the config, I can only reproduce with the
config attached to the original report. I can't see any reason why the
config matters for this bug, but perhaps it's enabling something that's
confusing the compiler somehow.
Anyway I'll post a patch to change the asm so the bug goes away.
cheers
^ permalink raw reply [flat|nested] 15+ messages in thread