[AArch32] Fix the build for M class semihosting

Message ID DB6PR0802MB23094BE16F74E11BF188F735FF690@DB6PR0802MB2309.eurprd08.prod.outlook.com
State New
Headers show
Series
  • [AArch32] Fix the build for M class semihosting
Related show

Commit Message

Tamar Christina Feb. 8, 2019, 6:34 p.m.
Hi All,

The M class cores don't support Semihosting v2 mixed mode, but we were
accidentally using the new immediates for it.  My last patch changed the
immediates which broke the build because doing a full multi-lib build
including M architectures now results in an assembler error instead of
silently doing the wrong thing.

This fixes the issue by changing the defines around such that According
to the specs any M class build uses the normal semihosting instructions
always.

Regtested on arm-none-eabi and no issues, using a build with m class
multilibs too.

Ok for master?

PS, I don't have commit rights so if OK can someone commit for me?

Thanks,
Tamar
--

Comments

Corinna Vinschen Feb. 11, 2019, 11:50 a.m. | #1
On Feb  8 18:34, Tamar Christina wrote:
> Hi All,

> 

> The M class cores don't support Semihosting v2 mixed mode, but we were

> accidentally using the new immediates for it.  My last patch changed the

> immediates which broke the build because doing a full multi-lib build

> including M architectures now results in an assembler error instead of

> silently doing the wrong thing.

> 

> This fixes the issue by changing the defines around such that According

> to the specs any M class build uses the normal semihosting instructions

> always.

> 

> Regtested on arm-none-eabi and no issues, using a build with m class

> multilibs too.

> 

> Ok for master?


Pushed.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

Patch

From fa0b6a2ccdc65c4b32d7b50367ff6e9714ab4ac0 Mon Sep 17 00:00:00 2001
From: Tamar Christina <tamar.christina@arm.com>
Date: Fri, 8 Feb 2019 17:13:24 +0000
Subject: [PATCH] AArch32: Fix the build for M class semihosting

The M class cores don't support Semihosting v2 mixed mode, but we were
accidentally using the new immediates for it.  My last patch changed the
immediates which broke the build because doing a full multi-lib build
including M architectures now results in an assembler error instead of
silently doing the wrong thing.

This fixes the issue by changing the defines around such that According
to the specs any M class build uses the normal semihosting instructions.

Regtested on arm-none-eabi and no issues, using a build with m class
multilibs too.
---
 libgloss/arm/swi.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libgloss/arm/swi.h b/libgloss/arm/swi.h
index 8f50ee7d9b..267d164d22 100644
--- a/libgloss/arm/swi.h
+++ b/libgloss/arm/swi.h
@@ -30,7 +30,9 @@ 
 
 
 /* Now the SWI numbers and reason codes for RDI (Angel) monitors.  */
-#if defined (SEMIHOST_V2) && defined (SEMIHOST_V2_MIXED_MODE)
+#if defined (SEMIHOST_V2) \
+    && defined (SEMIHOST_V2_MIXED_MODE) \
+    && !defined (THUMB_VXM)
   #define AngelSWI_ARM			0xE10F0070 /* HLT #0xF000 A32.  */
   #ifdef __thumb__
     #define AngelSWI			0xBABC /* HLT #0x3c T32.  */
-- 
2.20.1