Skip to contentSkip to conversation

sparc32: fix trap number in call to kgdb_handle_exception

PATCH In review Sam Ravnborg 2 participants 3 messages Mar 30, 2016 – Apr 21, 2016 SPARC + UltraSPARC (sparc/sparc64)

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 sparc32: fix trap number in call to kgdb_handle_exception

From ae7ae09c77621331f8aa18f2281f74640fcc39f2 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg <[email protected]>
Date: Wed, 30 Mar 2016 20:39:11 +0200
Subject: [PATCH 1/1] sparc32: fix trap number in call to kgdb_handle_exception

While browsing this code for other reasons this disprecancy was noticed. It looks like the code originates from sparc64.

The trap number is in the generic code only used as argument to a few methods that for sparc is simple stub functions. So the trap number is not used, thus this patch does not have any functional impact.

---

I was tempted to modify kgdb_trap to take the trap number as argument, like we do for sparc64.
But in first try I did the minimal fix.

If you prefer I will redo the patch so we pass the trap number in %o1 and pt_regs in %o2 like we do on sparc64.

Sam

 arch/sparc/kernel/kgdb_32.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/sparc/kernel/kgdb_32.c +1 -1
index dcf2108..a5774e0 100644
@@ -147,7 +147,7 @@ asmlinkage void kgdb_trap(struct pt_regs *regs)
 	flushw_all();
 
 	local_irq_save(flags);
-	kgdb_handle_exception(0x172, SIGTRAP, 0, regs);
+	kgdb_handle_exception(0xfd, SIGTRAP, 0, regs);
 	local_irq_restore(flags);
 }
 
Signature · 1 line
2.5.0
#1 lore raw
Quoted 16 lines · Sam Ravnborg
Quoted 1 line

From ae7ae09c77621331f8aa18f2281f74640fcc39f2 Mon Sep 17 00:00:00 2001

From: Sam Ravnborg <[email protected]>
Date: Wed, 30 Mar 2016 20:39:11 +0200
Subject: [PATCH 1/1] sparc32: fix trap number in call to kgdb_handle_exception

While browsing this code for other reasons this disprecancy was noticed. It looks like the code originates from sparc64.

The trap number is in the generic code only used as argument to a few methods that for sparc is simple stub functions. So the trap number is not used, thus this patch does not have any functional impact.

---

Quoted 7 lines

I was tempted to modify kgdb_trap to take the trap number as argument, like we do for sparc64.
But in first try I did the minimal fix.

If you prefer I will redo the patch so we pass the trap number in %o1 and pt_regs in %o2 like we do on sparc64.

Scrap this patch.

I ended up doing as I suggested above. Needs to sort out a toolchain issue so I at least have done a test build before I submit it.

Sam

maintainer
#2 lore raw
In reply to Sam Ravnborg

From: Sam Ravnborg <[email protected]>
Date: Thu, 31 Mar 2016 07:19:41 +0200

Quoted 21 lines · Sam Ravnborg
Quoted 20 lines
Quoted 1 line

From ae7ae09c77621331f8aa18f2281f74640fcc39f2 Mon Sep 17 00:00:00 2001

From: Sam Ravnborg <[email protected]>
Date: Wed, 30 Mar 2016 20:39:11 +0200
Subject: [PATCH 1/1] sparc32: fix trap number in call to kgdb_handle_exception

While browsing this code for other reasons this disprecancy was noticed. It looks like the code originates from sparc64.

The trap number is in the generic code only used as argument to a few methods that for sparc is simple stub functions. So the trap number is not used, thus this patch does not have any functional impact.

---

I was tempted to modify kgdb_trap to take the trap number as argument, like we do for sparc64.
But in first try I did the minimal fix.

Quoted 7 lines
Quoted 3 lines

If you prefer I will redo the patch so we pass the trap number in %o1 and pt_regs in %o2 like we do on sparc64.

Scrap this patch.

I ended up doing as I suggested above. Needs to sort out a toolchain issue so I at least have done a test build before I submit it.

Ok.