linux-kernel - [PATCH 1/2] ARC: define __ALIGN_STR and _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20200311162644.7667-1-Eugeniy.Paltsev@synopsys.com>
Date:   Wed, 11 Mar 2020 19:26:43 +0300
From:   Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
To:     linux-snps-arc@...ts.infradead.org,
        Vineet Gupta <Vineet.Gupta1@...opsys.com>
Cc:     linux-kernel@...r.kernel.org,
        Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
        Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
Subject: [PATCH 1/2] ARC: define __ALIGN_STR and __ALIGN symbols for ARC

As of today ARC uses generic __ALIGN_STR and __ALIGN symbol
definitions from "include/linux/linkage.h"
They are defined to ".align 4,0x90" which instructed the assembler
to use `0x90` as a fill byte when aligning functions declared with
ENTRY or similar macroses. This leads to generated weird instructions
in code (when alignment is used) like "ldh_s r12,[r0,0x20]" which is
encoded as 0x9090 for ARCv2.

Let's use ".align 4" which insert a "nop_s" instruction instead.

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
---
 arch/arc/include/asm/linkage.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arc/include/asm/linkage.h b/arch/arc/include/asm/linkage.h
index d9ee43c6b7db..fe19f1d412e7 100644
--- a/arch/arc/include/asm/linkage.h
+++ b/arch/arc/include/asm/linkage.h
@@ -29,6 +29,8 @@
 .endm

 #define ASM_NL		 `	/* use '`' to mark new line in macro */
+#define __ALIGN		.align 4
+#define __ALIGN_STR	__stringify(__ALIGN)

 /* annotation for data we want in DCCM - if enabled in .config */
 .macro ARCFP_DATA nm
-- 
2.21.1