Skip to contentSkip to conversation

arm: make arch memset/memcpy to work with Thumb2 builds

PATCH New Stefan Agner 4 participants 11 messages Nov 19, 2014 – Nov 21, 2014 Arm (32-bit)

lore
Share & tools
lore

Stefan Agner

author
#0 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Resynchronize memcpy/memset with kernel and build them explicitly in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). Hoever, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set.

Also add implicit-it=always to AFLAGS when building for Thumb2. Furthermore add no-warn-deprecated option to AFLAGS to rid of
deprecated unified syntax:
arch/arm/lib/memcpy.S: Assembler messages:
arch/arm/lib/memcpy.S:153: Warning: conditional infixes are deprecated in unified syntax arch/arm/lib/memcpy.S:154: Warning: conditional infixes are deprecated in unified syntax
...

Signed-off-by Stefan Agner <[email protected]>

---
This patch grew out of a issue we have seen on our Vybrid based module. My first proposal only covered memcpy. This patchset synchronizes the memcpy/memset assembly with the kernel and makes sure both files are built in Thumb mode.

This patchset is tested with Vybrid in ARM and Thumb2 mode.

 arch/arm/config.mk               |   5 +-
 arch/arm/include/asm/assembler.h |  33 ++++++++++--
 arch/arm/lib/memcpy.S            |  75 ++++++++++++++++++--------
 arch/arm/lib/memset.S            | 112 ++++++++++++++++++++-------------------
 4 files changed, 141 insertions(+), 84 deletions(-)
arch/arm/config.mk +4 -1
index f0eafd6..7336455 100644
@@ -26,7 +26,10 @@ PLATFORM_CPPFLAGS += -D__ARM__
 
 # Choose between ARM/Thumb instruction sets
 ifeq ($(CONFIG_SYS_THUMB_BUILD),y)
-PF_CPPFLAGS_ARM := $(call cc-option, -mthumb -mthumb-interwork,\
+AFLAGS_AUTOIT	:= $(call as-option,-Wa$(comma)-mimplicit-it=always,-Wa$(comma)-mauto-it)
+AFLAGS_NOWARN	:=$(call as-option,-Wa$(comma)-mno-warn-deprecated,-Wa$(comma)-W)
+PF_CPPFLAGS_ARM := $(AFLAGS_AUTOIT) $(AFLAGS_NOWARN) \
+			$(call cc-option, -mthumb -mthumb-interwork,\
 			$(call cc-option,-marm,)\
 			$(call cc-option,-mno-thumb-interwork,)\
 		)
arch/arm/include/asm/assembler.h +28 -5
index 5e4789b..11b80fb 100644
@@ -14,12 +14,14 @@
  *  assembler source.
  */
 
+#include <config.h>
+
 /*
  * Endian independent macros for shifting bytes within registers.
  */
 #ifndef __ARMEB__
-#define pull		lsr
-#define push		lsl
+#define lspull		lsr
+#define lspush		lsl
 #define get_byte_0	lsl #0
 #define get_byte_1	lsr #8
 #define get_byte_2	lsr #16

@@ -29,8 +31,8 @@
 #define put_byte_2	lsl #16
 #define put_byte_3	lsl #24
 #else
-#define pull		lsl
-#define push		lsr
+#define lspull		lsl
+#define lspush		lsr
 #define get_byte_0	lsr #24
 #define get_byte_1	lsr #16
 #define get_byte_2	lsr #8

@@ -54,7 +56,28 @@
 #define PLD(code...)
 #endif
 
+	.irp	c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
+	.macro	ret\c, reg
+#if defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__)
+	mov\c	pc, \reg
+#else
+	.ifeqs	"\reg", "lr"
+	bx\c	\reg
+	.else
+	mov\c	pc, \reg
+	.endif
+#endif
+	.endm
+	.endr
+
 /*
- * Cache alligned
+ * Cache aligned, used for optimized memcpy/memset
+ * In the kernel this is only enabled for Feroceon CPU's...
+ * We disable it especially for Thumb builds since those instructions
+ * are not made in a Thumb ready way...
  */
+#ifdef CONFIG_SYS_THUMB_BUILD
+#define CALGN(code...)
+#else
 #define CALGN(code...) code
+#endif
arch/arm/lib/memcpy.S +52 -23

111 lines not on this page · raw message

arch/arm/lib/memset.S +57 -55

171 lines not on this page · raw message

Signature · 1 line
2.1.3
#1 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Hello Stefan,

Quoted 14 lines · Stefan Agner

Resynchronize memcpy/memset with kernel and build them explicitly in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). Hoever, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set.

Also add implicit-it=always to AFLAGS when building for Thumb2. Furthermore add no-warn-deprecated option to AFLAGS to rid of deprecated unified syntax:

Quoted 4 lines

arch/arm/lib/memcpy.S: Assembler messages:
arch/arm/lib/memcpy.S:153: Warning: conditional infixes are deprecated in unified syntax arch/arm/lib/memcpy.S:154: Warning: conditional infixes are deprecated in unified syntax
...

Any particular reason not to fix these warnings instead? It Is just a matter of making the conditionals suffixes. [I guess you can even disassemble to file to get the UAL represenation]. Or are there gas version around which actually choke on that?

Regards,
Jeroen

author
#2 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Hi Jeroen,

Quoted 22 lines · Jeroen Hofstee

Hello Stefan,

Quoted 14 lines · Stefan Agner

Resynchronize memcpy/memset with kernel and build them explicitly in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). Hoever, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set.

Also add implicit-it=always to AFLAGS when building for Thumb2. Furthermore add no-warn-deprecated option to AFLAGS to rid of deprecated unified syntax:

Quoted 4 lines

arch/arm/lib/memcpy.S: Assembler messages:
arch/arm/lib/memcpy.S:153: Warning: conditional infixes are deprecated in unified syntax arch/arm/lib/memcpy.S:154: Warning: conditional infixes are deprecated in unified syntax
...

Quoted 4 lines

Any particular reason not to fix these warnings instead? It Is just a matter of making the conditionals suffixes. [I guess you can even disassemble to file to get the UAL represenation]. Or are there gas version around which actually choke on that?

No particular reason, I did not know how to fix this without digging into it. Hence, after I discovered this, I checked why those warnings do not happen for the kernel, then I applied just the AFLAGS the kernel is using. I guess fixing the underlying issue is the better option, and doing this also for the kernel would be the best way... Maybe the kernel community also knows better why they choose to use the AFLAGS instead (and if there are gas version which do have problems with a proper fix)...

--
Stefan

Quoted 3 lines

Regards,
Jeroen

#3 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Hello Stefan,

Quoted 27 lines · Stefan Agner

Hi Jeroen,

Quoted 16 lines · Jeroen Hofstee

Hello Stefan,

Quoted 12 lines · Stefan Agner

Resynchronize memcpy/memset with kernel and build them explicitly in Thumb2 mode (unified syntax). Those assembler files can be built and linked in ARM mode too, however when calling them from Thumb2 built code, the stack got corrupted and the copy did not succeed (the exact details have not been traced back). Hoever, the Linux kernel builds those files in Thumb2 mode. Hence U-Boot should build them in Thumb2 mode too when CONFIG_SYS_THUMB_BUILD is set.

Also add implicit-it=always to AFLAGS when building for Thumb2. Furthermore add no-warn-deprecated option to AFLAGS to rid of deprecated unified syntax:

Quoted 8 lines
Quoted 4 lines

arch/arm/lib/memcpy.S: Assembler messages:
arch/arm/lib/memcpy.S:153: Warning: conditional infixes are deprecated in unified syntax arch/arm/lib/memcpy.S:154: Warning: conditional infixes are deprecated in unified syntax
...

Any particular reason not to fix these warnings instead? It Is just a matter of making the conditionals suffixes. [I guess you can even disassemble to file to get the UAL represenation]. Or are there gas version around which actually choke on that?

Quoted 9 lines

No particular reason, I did not know how to fix this without digging into it. Hence, after I discovered this, I checked why those warnings do not happen for the kernel, then I applied just the AFLAGS the kernel is using. I guess fixing the underlying issue is the better option, and doing this also for the kernel would be the best way... Maybe the kernel community also knows better why they choose to use the AFLAGS instead (and if there are gas version which do have problems with a proper fix)...

for what it is worth, I have attached patch hanging around, but I never actually tested it. It is for the current version.

Regards,
Jeroen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-arm-memset-make-it-UAL-compliant.patch
Type: text/x-patch
Size: 2546 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141120/a1ea6c16/attachment.bin>

#4 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Quoted 10 lines · Stefan Agner
Quoted 9 lines

No particular reason, I did not know how to fix this without digging into it. Hence, after I discovered this, I checked why those warnings do not happen for the kernel, then I applied just the AFLAGS the kernel is using. I guess fixing the underlying issue is the better option, and doing this also for the kernel would be the best way... Maybe the kernel community also knows better why they choose to use the AFLAGS instead (and if there are gas version which do have problems with a proper fix)...

Quoted 21 lines · jeroen at myspectrum.nl

for what it is worth, I have attached patch hanging around, but I never actually tested it. It is for the current version.

Quoted 2 lines

From c151254b3de49d8fccb69ab4f9442d884b9ff85c Mon Sep 17 00:00:00 2001

From: Jeroen Hofstee <[email protected]>
Date: Thu, 20 Nov 2014 14:06:26 +0100
Subject: [PATCH] arm: memset: make it UAL compliant

---
arch/arm/lib/memset.S | 40 ++++++++++++++++++++--------------------

1 file changed, 20 insertions(+), 20 deletions(-)
arch/arm/lib/memset.S +0 -0
index 0cdf895..4fe38f6 100644
@@ -18,8 +18,8 @@

1: subs r2, r2, #4 @ 1 do we have enough

	blt	5f			@ 1 bytes to align with?
	cmp	r3, #2			@ 1

arch/arm/lib/memset.S

Quoted 4 lines
arch/arm/lib/memset.S +2 -2
-	strltb	r1, [r0], #1		@ 1
-	strleb	r1, [r0], #1		@ 1
+	strblt	r1, [r0], #1		@ 1
+	strble	r1, [r0], #1		@ 1

To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc.

Fwiw,
Bill.

#5 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Hi,

Quoted 5 lines · Bill Pringlemeir
Quoted 5 lines

---
arch/arm/lib/memset.S | 40 ++++++++++++++++++++--------------------

1 file changed, 20 insertions(+), 20 deletions(-)
Quoted 16 lines

arch/arm/lib/memset.S

Quoted 12 lines
arch/arm/lib/memset.S +0 -0
index 0cdf895..4fe38f6 100644
@@ -18,8 +18,8 @@

1: subs r2, r2, #4 @ 1 do we have enough

	blt	5f			@ 1 bytes to align with?
	cmp	r3, #2			@ 1
arch/arm/lib/memset.S +2 -2
-	strltb	r1, [r0], #1		@ 1
-	strleb	r1, [r0], #1		@ 1
+	strblt	r1, [r0], #1		@ 1
+	strble	r1, [r0], #1		@ 1

To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc.

yes, I should be trivial to test (and find the trivial problem, with the patch I attached). I am wondering though if all version of gas accept the suffix notation... any idea?

Regards,
Jeroen

#6 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Quoted 21 lines
Quoted 21 lines
Quoted 13 lines

---
arch/arm/lib/memset.S | 40 ++++++++++++++++++++--------------------

1 file changed, 20 insertions(+), 20 deletions(-)
arch/arm/lib/memset.S +0 -0
index 0cdf895..4fe38f6 100644
Quoted 1 line
Quoted 1 line

-18,8 +18,8 @@

1: subs r2, r2, #4 @ 1 do we have enough

	blt	5f			@ 1 bytes to align with?
	cmp	r3, #2			@ 1

arch/arm/lib/memset.S

Quoted 4 lines
arch/arm/lib/memset.S +2 -2
-	strltb	r1, [r0], #1		@ 1
-	strleb	r1, [r0], #1		@ 1
+	strblt	r1, [r0], #1		@ 1
+	strble	r1, [r0], #1		@ 1

To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc.

Quoted 3 lines · jeroen at myspectrum.nl

yes, I should be trivial to test (and find the trivial problem, with the patch I attached). I am wondering though if all version of gas accept the suffix notation... any idea?

One part of the answer is here,

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=history;f=gas/config/tc-arm.c;hb=HEAD

The 'strCCb' version is definitely more popular in older ARM books. Certainly there could be bugs and/or patched versions that make a difference. Probably it would be helpful to know what versions are supported.

Back in 1999 it seems that the code at least tries to take conditions anywhere,

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-arm.c;hb=858f4ff6ff40a73f2a569fc8886157568f08c6db#l6099

I think it is most likely to result in a parse error if it wasn't supported. Any version since Thumb2/Unified (2003-2005?) was introduced should be accepting this syntax with less issues. Ie, it seems like a better way forward.

Historical versions are here,

http://ftp.mirrorservice.org/sites/sourceware.org/pub/binutils/old-releases/

Who knows if some vendor patched things to mess something up? Probably grabbing an older 'gas' version and verifying it was the same binary before/after the patch would probably be fair confirmation? I don't think you can 100% guarantee this doesn't break with some archaic vendors gas.

Fwiw,
Bill Pringlemeir.

#7 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Hi,

Quoted 45 lines · Bill Pringlemeir
Quoted 19 lines
Quoted 19 lines
Quoted 12 lines

---
arch/arm/lib/memset.S | 40 ++++++++++++++++++++--------------------

1 file changed, 20 insertions(+), 20 deletions(-)
arch/arm/lib/memset.S +0 -0
index 0cdf895..4fe38f6 100644
Quoted 1 line
Quoted 1 line

-18,8 +18,8 @@

1: subs r2, r2, #4 @ 1 do we have enough

	blt	5f			@ 1 bytes to align with?
	cmp	r3, #2			@ 1

arch/arm/lib/memset.S

Quoted 4 lines
arch/arm/lib/memset.S +2 -2
-	strltb	r1, [r0], #1		@ 1
-	strleb	r1, [r0], #1		@ 1
+	strblt	r1, [r0], #1		@ 1
+	strble	r1, [r0], #1		@ 1

To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc.

Quoted 3 lines · jeroen at myspectrum.nl

yes, I should be trivial to test (and find the trivial problem, with the patch I attached). I am wondering though if all version of gas accept the suffix notation... any idea?

One part of the answer is here,

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=history;f=gas/config/tc-arm.c;hb=HEAD

The 'strCCb' version is definitely more popular in older ARM books. Certainly there could be bugs and/or patched versions that make a difference. Probably it would be helpful to know what versions are supported.

Back in 1999 it seems that the code at least tries to take conditions anywhere,

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-arm.c;hb=858f4ff6ff40a73f2a569fc8886157568f08c6db#l6099

I think it is most likely to result in a parse error if it wasn't supported. Any version since Thumb2/Unified (2003-2005?) was introduced should be accepting this syntax with less issues. Ie, it seems like a better way forward.

Historical versions are here,

Quoted 7 lines

http://ftp.mirrorservice.org/sites/sourceware.org/pub/binutils/old-releases/

Who knows if some vendor patched things to mess something up? Probably grabbing an older 'gas' version and verifying it was the same binary before/after the patch would probably be fair confirmation? I don't think you can 100% guarantee this doesn't break with some archaic vendors gas.

Ok thanks for digging that up, that doesn't sound like a problem then. Stefan, can you check if you can actually fix the warnings instead of suppressing them?

Regards,
Jeroen

author
#8 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Quoted 56 lines · Jeroen Hofstee

Hi,

Quoted 45 lines · Bill Pringlemeir
Quoted 19 lines
Quoted 19 lines
Quoted 12 lines

---
arch/arm/lib/memset.S | 40 ++++++++++++++++++++--------------------

1 file changed, 20 insertions(+), 20 deletions(-)
arch/arm/lib/memset.S +0 -0
index 0cdf895..4fe38f6 100644
Quoted 1 line
Quoted 1 line

-18,8 +18,8 @@

1: subs r2, r2, #4 @ 1 do we have enough

	blt	5f			@ 1 bytes to align with?
	cmp	r3, #2			@ 1

arch/arm/lib/memset.S

Quoted 4 lines
arch/arm/lib/memset.S +2 -2
-	strltb	r1, [r0], #1		@ 1
-	strleb	r1, [r0], #1		@ 1
+	strblt	r1, [r0], #1		@ 1
+	strble	r1, [r0], #1		@ 1

To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc.

Quoted 3 lines · jeroen at myspectrum.nl

yes, I should be trivial to test (and find the trivial problem, with the patch I attached). I am wondering though if all version of gas accept the suffix notation... any idea?

One part of the answer is here,

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=history;f=gas/config/tc-arm.c;hb=HEAD

The 'strCCb' version is definitely more popular in older ARM books. Certainly there could be bugs and/or patched versions that make a difference. Probably it would be helpful to know what versions are supported.

Back in 1999 it seems that the code at least tries to take conditions anywhere,

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-arm.c;hb=858f4ff6ff40a73f2a569fc8886157568f08c6db#l6099

I think it is most likely to result in a parse error if it wasn't supported. Any version since Thumb2/Unified (2003-2005?) was introduced should be accepting this syntax with less issues. Ie, it seems like a better way forward.

Historical versions are here,

Quoted 7 lines

http://ftp.mirrorservice.org/sites/sourceware.org/pub/binutils/old-releases/

Who knows if some vendor patched things to mess something up? Probably grabbing an older 'gas' version and verifying it was the same binary before/after the patch would probably be fair confirmation? I don't think you can 100% guarantee this doesn't break with some archaic vendors gas.

Quoted 4 lines

Ok thanks for digging that up, that doesn't sound like a problem then. Stefan, can you check if you can actually fix the warnings instead of suppressing them?

Ok, I could apply the changes from your patch and it fixed the warnings in memset.S. However, when I build the file in ARM mode then (without CONFIG_SYS_THUMB_BUILD set). I get this:

arch/arm/lib/memset.S: Assembler messages:
arch/arm/lib/memset.S:92: Error: bad instruction `stmiage ip!,{r1,r3-r8,lr}'
arch/arm/lib/memset.S:93: Error: bad instruction `stmiage ip!,{r1,r3-r8,lr}'
arch/arm/lib/memset.S:95: Error: bad instruction `ldmfdeq sp!,{r4-r8,pc}'
arch/arm/lib/memset.S:98: Error: bad instruction `stmiane ip!,{r1,r3-r8,lr}'
arch/arm/lib/memset.S:100: Error: bad instruction stmiane ip!,{r4-r7}' arch/arm/lib/memset.S:106: Error: bad instruction stmiane ip!,{r1,r3}' arch/arm/lib/memset.S:114: Error: bad instruction strbne r1,[ip],#1' arch/arm/lib/memset.S:115: Error: bad instruction strbne r1,[ip],#1' arch/arm/lib/memset.S:117: Error: bad instruction strbne r1,[ip],#1' arch/arm/lib/memset.S:123: Error: bad instruction strblt r1,[ip],#1' arch/arm/lib/memset.S:124: Error: bad instruction `strble r1,[ip],#1'

--
Stefan

Quoted 2 lines

Regards,
Jeroen

#9 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

Quoted 6 lines · Jeroen Hofstee
Quoted 4 lines

Ok thanks for digging that up, that doesn't sound like a problem then. Stefan, can you check if you can actually fix the warnings instead of suppressing them?

Quoted 6 lines · stefan at agner.ch

Ok, I could apply the changes from your patch and it fixed the warnings in memset.S. However, when I build the file in ARM mode then (without CONFIG_SYS_THUMB_BUILD set). I get this:

arch/arm/lib/memset.S: Assembler messages: arch/arm/lib/memset.S:92:
Error: bad instruction `stmiage ip!,{r1,r3-r8,lr}'

I think you need '.syntax unified' if you want those in ARM mode. I guess you found that out too? I see,

+ .syntax unified
+#ifdef CONFIG_SYS_THUMB_BUILD
+ .thumb
+ .thumb_func
+#endif

in '[PATCH v2] arm: build arch memset/memcpy in Thumb2 mode'; so this solved it?

I think it is a very nice feature to have Thumb2 on Vybrid. Many boot devices may have limited bandwidth compared to the running system. Thanks for your work.

Regards,
Bill Pringlemeir

#10 lore raw

PATCH 1/1 arm: make arch memset/memcpy to work with Thumb2 builds

In reply to Jeroen Hofstee

Hello Jeroen,

Adding Stefan as it seems he was dropped from the recipients list.

Plus :

Quoted 56 lines · Jeroen Hofstee

Hi,

Quoted 45 lines · Bill Pringlemeir
Quoted 19 lines
Quoted 19 lines
Quoted 12 lines

---
arch/arm/lib/memset.S | 40 ++++++++++++++++++++--------------------

1 file changed, 20 insertions(+), 20 deletions(-)
arch/arm/lib/memset.S +0 -0
index 0cdf895..4fe38f6 100644
Quoted 1 line
Quoted 1 line

-18,8 +18,8 @@

1: subs r2, r2, #4 @ 1 do we have enough

	blt	5f			@ 1 bytes to align with?
	cmp	r3, #2			@ 1

arch/arm/lib/memset.S

Quoted 4 lines
arch/arm/lib/memset.S +2 -2
-	strltb	r1, [r0], #1		@ 1
-	strleb	r1, [r0], #1		@ 1
+	strblt	r1, [r0], #1		@ 1
+	strble	r1, [r0], #1		@ 1

To test this, can we just use 'objdump'. The hex codes should be identical; there is only one encoding. It should produce the same binaries. No need to run test-suites, etc.

Quoted 3 lines · jeroen at myspectrum.nl

yes, I should be trivial to test (and find the trivial problem, with the patch I attached). I am wondering though if all version of gas accept the suffix notation... any idea?

One part of the answer is here,

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=history;f=gas/config/tc-arm.c;hb=HEAD

The 'strCCb' version is definitely more popular in older ARM books. Certainly there could be bugs and/or patched versions that make a difference. Probably it would be helpful to know what versions are supported.

Back in 1999 it seems that the code at least tries to take conditions anywhere,

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gas/config/tc-arm.c;hb=858f4ff6ff40a73f2a569fc8886157568f08c6db#l6099

I think it is most likely to result in a parse error if it wasn't supported. Any version since Thumb2/Unified (2003-2005?) was introduced should be accepting this syntax with less issues. Ie, it seems like a better way forward.

Historical versions are here,

Quoted 7 lines

http://ftp.mirrorservice.org/sites/sourceware.org/pub/binutils/old-releases/

Who knows if some vendor patched things to mess something up? Probably grabbing an older 'gas' version and verifying it was the same binary before/after the patch would probably be fair confirmation? I don't think you can 100% guarantee this doesn't break with some archaic vendors gas.

Quoted 3 lines

Ok thanks for digging that up, that doesn't sound like a problem then. Stefan, can you check if you can actually fix the warnings instead of suppressing them?

(in the right thread this time) Stefan, can you also drop the -mauto-it part?

Quoted 2 lines

Regards,
Jeroen

Amicalement,

Signature · 1 line
Albert.