x86/alternatives: fix build issue with binutils before 2.28

  The usage of the BIT() macro in asm code was introduced in 6.3 in by
commit 5d1dd961e743 ("x86/alternatives: Add alt_instr.flags") but this
macro uses "1UL" in the shift operations, while gas before 2.28 do not
support the "L" suffix after a number, and those before 2.27 do not
support the "U" suffix, resulting in build errors such as the following
with such versions:

  ./arch/x86/include/asm/uaccess_64.h:124: Error: found 'L', expected: ')'
  ./arch/x86/include/asm/uaccess_64.h:124: Error: junk at end of line,
  first unrecognized character is `L'

There's a single use of this macro here, let's revert to (1 << 0) that
works with such older binutils.

Cc: Jingbo Xu <jefflexu@linux.alibaba.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Link: https://lore.kernel.org/lkml/a9aae568-3046-306c-bd71-92c1fc8eeddc@linux.alibaba.com/
Signed-off-by: Willy Tarreau <w@1wt.eu>
---

Boris, I understood from your message that 2.28 was the first working version,
so that's what I mentioned here. My tests showed that 2.27 wasn't sufficient
and that 2.29 was OK. If I was wrong and it's 2.29 instead, feel free to edit
the subject line, description and the comment, I'm totally fine with this!


 arch/x86/include/asm/alternative.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

On 4/18/23 2:42 PM, Willy Tarreau wrote:
> The usage of the BIT() macro in asm code was introduced in 6.3 in by
> commit 5d1dd961e743 ("x86/alternatives: Add alt_instr.flags") but this
> macro uses "1UL" in the shift operations, while gas before 2.28 do not
> support the "L" suffix after a number, and those before 2.27 do not
> support the "U" suffix, resulting in build errors such as the following
> with such versions:
> 
>   ./arch/x86/include/asm/uaccess_64.h:124: Error: found 'L', expected: ')'
>   ./arch/x86/include/asm/uaccess_64.h:124: Error: junk at end of line,
>   first unrecognized character is `L'
> 
> There's a single use of this macro here, let's revert to (1 << 0) that
> works with such older binutils.
> 
> Cc: Jingbo Xu <jefflexu@linux.alibaba.com>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Link: https://lore.kernel.org/lkml/a9aae568-3046-306c-bd71-92c1fc8eeddc@linux.alibaba.com/
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> 
> Boris, I understood from your message that 2.28 was the first working version,
> so that's what I mentioned here. My tests showed that 2.27 wasn't sufficient
> and that 2.29 was OK. If I was wrong and it's 2.29 instead, feel free to edit
> the subject line, description and the comment, I'm totally fine with this!
> 
> 
>  arch/x86/include/asm/alternative.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
> index e2975a32d443..b119685c0b31 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -8,7 +8,7 @@
>  
>  #define ALT_FLAGS_SHIFT		16
>  
> -#define ALT_FLAG_NOT		BIT(0)
> +#define ALT_FLAG_NOT		(1 << 0) /* note: gas < 2.28 can't use BIT(0) */
>  #define ALT_NOT(feature)	((ALT_FLAG_NOT << ALT_FLAGS_SHIFT) | (feature))
>  
>  #ifndef __ASSEMBLY__

It works for me.

Tested-by: Jingbo Xu <jefflexu@linux.alibaba.com>
  

On Tue, Apr 18, 2023 at 08:42:28AM +0200, Willy Tarreau wrote:
> Boris, I understood from your message that 2.28 was the first working version,
> so that's what I mentioned here. My tests showed that 2.27 wasn't sufficient
> and that 2.29 was OK.

No, you have it right above:

U suffix - 2.27
L/LL suffixes - 2.28

I was wondering where to put that info for future reference but didn't
find a good place so I extended your commit message with it. Now at
least we have left bread crumbs in case we need it in the future.

Thx.
  

On Tue, Apr 18, 2023 at 12:02:12PM +0200, Borislav Petkov wrote:
> On Tue, Apr 18, 2023 at 08:42:28AM +0200, Willy Tarreau wrote:
> > Boris, I understood from your message that 2.28 was the first working version,
> > so that's what I mentioned here. My tests showed that 2.27 wasn't sufficient
> > and that 2.29 was OK.
> 
> No, you have it right above:
> 
> U suffix - 2.27
> L/LL suffixes - 2.28
> 
> I was wondering where to put that info for future reference but didn't
> find a good place so I extended your commit message with it. Now at
> least we have left bread crumbs in case we need it in the future.

I wondered the same which is why I left it in the comment as a warning
for future wanderers.

Thanks!
Willy