[Xenomai-core] kgdb over ipipe

[Xenomai-core] kgdb over ipipe

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 1460 bytes --]

Hi,

this is the preliminary, though already usable result of my recent
effort to extend the tool situation for Xenomai: A kgdb patch series for
2.6.15 on x86. It already works quite well but likely does not yet catch
all fatal scenarios (e.g. page faults in the Xenomai domain).

To apply it, you first need to run the standard kgdb patch series
against a vanilla 2.6.15 (I tested .3 and .5), and then extend that
series like follows:

prepare-kgdb-ipipe-x86.patch
adeos-ipipe-2.6.15-i386-1.2-01.patch
kgdb-ipipe.patch
kgdb-ipipe-x86.patch

Note that the adeos patch is also vanilla, i.e. unmodified! I
successfully tested the debugger (via serial cable) by putting a
breakpoint at rt_sem_v and then running the latency test - all fine.

You may want to patch gdb to improve its awareness of modules (see
kgdb.linsyssoft.com, I haven't tried yet), or you retrieve the module
base address (busybox's lsmod does this nicely e.g.) and issue
"add-symbol-file <path_to_your_module.ko> <base_address>" at the gdb prompt.

I once hacked RTAI's old hal patch and an old kgdb over 2.4 together.
That was definitely more patching work than this one here! I'm quite
confident that this time we will be able to maintain the debugger over a
longer period without too much effort. I also think that porting it over
other archs should be fairly easy.

But more on this will follow, I first have to apply the tool on a real
problem...

Jan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: prepare-kgdb-ipipe-x86.patch --]
[-- Type: text/x-patch; name="prepare-kgdb-ipipe-x86.patch", Size: 838 bytes --]

Index: linux-2.6.15.5/arch/i386/kernel/entry.S
===================================================================
--- linux-2.6.15.5.orig/arch/i386/kernel/entry.S	2006-04-07 16:42:54.000000000 +0200
+++ linux-2.6.15.5/arch/i386/kernel/entry.S	2006-04-07 16:47:23.000000000 +0200
@@ -123,7 +123,7 @@
 .previous
 
 
-KPROBE_ENTRY(ret_from_fork)
+ENTRY(ret_from_fork)
 	pushl %eax
 	call schedule_tail
 	GET_THREAD_INFO(%ebp)
@@ -470,7 +470,7 @@
 	pushl $do_simd_coprocessor_error
 	jmp error_code
 
-KPROBE_ENTRY(device_not_available)
+ENTRY(device_not_available)
 	pushl $-1			# mark this as an int
 	SAVE_ALL
 	movl %cr0, %eax
@@ -652,7 +652,7 @@
 	jmp error_code
 #endif
 
-KPROBE_ENTRY(spurious_interrupt_bug)
+ENTRY(spurious_interrupt_bug)
 	pushl $0
 	pushl $do_spurious_interrupt_bug
 	jmp error_code

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: kgdb-ipipe.patch --]
[-- Type: text/x-patch; name="kgdb-ipipe.patch", Size: 5248 bytes --]

Index: linux-2.6.15.3-kgdb/kernel/kgdb.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/kernel/kgdb.c	2006-04-08 04:54:37.000000000 +0200
+++ linux-2.6.15.3-kgdb/kernel/kgdb.c	2006-04-08 11:01:42.000000000 +0200
@@ -740,7 +740,7 @@
 	unsigned long flags;
 	int processor;
 
-	local_irq_save(flags);
+	local_irq_save_hw(flags);
 	processor = smp_processor_id();
 	kgdb_info[processor].debuggerinfo = regs;
 	kgdb_info[processor].task = current;
@@ -770,7 +770,7 @@
 	/* Signal the master processor that we are done */
 	atomic_set(&procindebug[processor], 0);
 	spin_unlock(&slavecpulocks[processor]);
-	local_irq_restore(flags);
+	local_irq_restore_hw(flags);
 }
 #endif
 
@@ -1033,7 +1033,7 @@
 	 * Interrupts will be restored by the 'trap return' code, except when
 	 * single stepping.
 	 */
-	local_irq_save(flags);
+	local_irq_save_hw(flags);
 
 	/* Hold debugger_active */
 	procid = smp_processor_id();
@@ -1056,7 +1056,7 @@
 	if (atomic_read(&cpu_doing_single_step) != -1 &&
 	    atomic_read(&cpu_doing_single_step) != procid) {
 		atomic_set(&debugger_active, 0);
-		local_irq_restore(flags);
+		local_irq_restore_hw(flags);
 		goto acquirelock;
 	}
 
@@ -1556,7 +1556,7 @@
 kgdb_restore:
 	/* Free debugger_active */
 	atomic_set(&debugger_active, 0);
-	local_irq_restore(flags);
+	local_irq_restore_hw(flags);
 
 	return error;
 }
@@ -1925,9 +1925,9 @@
 	if (!kgdb_connected || atomic_read(&debugger_active) != 0)
 		return 0;
 	if ((code == SYS_RESTART) || (code == SYS_HALT) || (code == SYS_POWER_OFF)){
-		local_irq_save(flags);
+		local_irq_save_hw(flags);
 		put_packet("X00");
-		local_irq_restore(flags);
+		local_irq_restore_hw(flags);
 	}
 	return NOTIFY_DONE;
 }		
@@ -1942,9 +1942,9 @@
 	if (!kgdb_connected || atomic_read(&debugger_active) != 0)
 		return;
 
-	local_irq_save(flags);
+	local_irq_save_hw(flags);
 	kgdb_msg_write(s, count);
-	local_irq_restore(flags);
+	local_irq_restore_hw(flags);
 }
 
 static struct console kgdbcons = {
Index: linux-2.6.15.3-kgdb/drivers/serial/8250_kgdb.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/drivers/serial/8250_kgdb.c	2006-04-08 04:54:37.000000000 +0200
+++ linux-2.6.15.3-kgdb/drivers/serial/8250_kgdb.c	2006-04-08 11:01:42.000000000 +0200
@@ -301,6 +301,10 @@
 			"GDB-stub", current_port) < 0)
 		printk(KERN_ERR "KGDB failed to request the serial IRQ (%d)\n",
 		       current_port->irq);
+#ifdef CONFIG_IPIPE
+	ipipe_control_irq(current_port->irq, 0,
+			IPIPE_HANDLE_MASK|IPIPE_STICKY_MASK|IPIPE_SYSTEM_MASK);
+#endif /* CONFIG_IPIPE */
 }
 
 static __init int kgdb_init_io(void)
Index: linux-2.6.15.3-kgdb/include/linux/kgdb.h
===================================================================
--- linux-2.6.15.3-kgdb.orig/include/linux/kgdb.h	2006-04-08 04:54:37.000000000 +0200
+++ linux-2.6.15.3-kgdb/include/linux/kgdb.h	2006-04-08 11:01:42.000000000 +0200
@@ -271,5 +271,14 @@
 /* Stubs for when KGDB is not set. */
 static const atomic_t debugger_active = ATOMIC_INIT(0);
 #endif				/* CONFIG_KGDB */
+
+#ifdef CONFIG_IPIPE
+void kgdb_catch_domain(struct ipipe_domain *ipd);
+int kgdb_catch_event_allowed(unsigned event);
+#else /* !CONFIG_IPIPE */
+#define kgdb_catch_domain(ipd)
+#define kgdb_catch_event_allowed(event) 1
+#endif /* CONFIG_IPIPE */
+
 #endif				/* _KGDB_H_ */
 #endif				/* __KERNEL__ */
Index: linux-2.6.15.3-kgdb/kernel/ipipe/generic.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/kernel/ipipe/generic.c	2006-04-08 04:54:37.000000000 +0200
+++ linux-2.6.15.3-kgdb/kernel/ipipe/generic.c	2006-04-08 11:01:42.000000000 +0200
@@ -29,6 +29,9 @@
 #ifdef CONFIG_PROC_FS
 #include <linux/proc_fs.h>
 #endif	/* CONFIG_PROC_FS */
+#ifdef CONFIG_KGDB
+#include <linux/kgdb.h>
+#endif	/* CONFIG_KGDB */
 
 MODULE_DESCRIPTION("I-pipe");
 MODULE_LICENSE("GPL");
@@ -106,6 +109,10 @@
 
 	printk(KERN_WARNING "I-pipe: Domain %s registered.\n", ipd->name);
 
+#ifdef CONFIG_KGDB
+	kgdb_catch_domain(ipd);
+#endif
+
 	/*
 	 * Finally, allow the new domain to perform its initialization
 	 * chores.
@@ -277,6 +284,11 @@
 		self = 1;
 	}
 
+#ifdef CONFIG_KGDB
+	if (!kgdb_catch_event_allowed(event))
+		return 0; /* silently ignore request */
+#endif
+
 	if (event >= IPIPE_NR_EVENTS)
 		return -EINVAL;
 
Index: linux-2.6.15.3-kgdb/lib/Kconfig.debug
===================================================================
--- linux-2.6.15.3-kgdb.orig/lib/Kconfig.debug	2006-04-08 04:54:37.000000000 +0200
+++ linux-2.6.15.3-kgdb/lib/Kconfig.debug	2006-04-08 11:01:42.000000000 +0200
@@ -250,7 +250,7 @@
 
 config KGDB_ONLY_MODULES
 	bool "KGDB: Use only kernel modules for I/O"
-	depends on MODULES
+	depends on MODULES && !IPIPE
 	help
 	  Use only kernel modules to configure KGDB I/O after the
 	  kernel is booted.
@@ -295,7 +295,7 @@
 endchoice
 
 config KGDBOE
-	tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE
+	tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE && !IPIPE
 	depends on m && KGDB
 	select NETPOLL
 	select NETPOLL_TRAP

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.4: kgdb-ipipe-x86.patch --]
[-- Type: text/x-patch; name="kgdb-ipipe-x86.patch", Size: 2652 bytes --]

Index: linux-2.6.15.3-kgdb/arch/i386/kernel/entry.S
===================================================================
--- linux-2.6.15.3-kgdb.orig/arch/i386/kernel/entry.S	2006-04-08 04:54:36.000000000 +0200
+++ linux-2.6.15.3-kgdb/arch/i386/kernel/entry.S	2006-04-08 11:01:52.000000000 +0200
@@ -194,7 +194,7 @@
 .previous
 
 
-ENTRY(ret_from_fork)
+KPROBE_ENTRY(ret_from_fork)
 	STI_COND_HW
 	pushl %eax
 	call schedule_tail
@@ -582,7 +582,7 @@
 	PUSH_XCODE(do_simd_coprocessor_error)
 	jmp error_code
 
-ENTRY(device_not_available)
+KPROBE_ENTRY(device_not_available)
 	pushl $-1			# mark this as an int
 	SAVE_ALL
 	DIVERT_EXCEPTION(device_not_available)
@@ -767,7 +767,7 @@
 	jmp error_code
 #endif
 
-ENTRY(spurious_interrupt_bug)
+KPROBE_ENTRY(spurious_interrupt_bug)
 	pushl $0
 	PUSH_XCODE(do_spurious_interrupt_bug)
 	jmp error_code
Index: linux-2.6.15.3-kgdb/arch/i386/kernel/ipipe-root.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/arch/i386/kernel/ipipe-root.c	2006-04-08 04:54:36.000000000 +0200
+++ linux-2.6.15.3-kgdb/arch/i386/kernel/ipipe-root.c	2006-04-08 11:01:52.000000000 +0200
@@ -34,6 +34,9 @@
 #include <asm/irq.h>
 #include <asm/desc.h>
 #include <asm/io.h>
+#ifdef CONFIG_KGDB
+#include <linux/kgdb.h>
+#endif  /* CONFIG_KGDB */
 #ifdef CONFIG_X86_LOCAL_APIC
 #include <asm/tlbflush.h>
 #include <asm/fixmap.h>
@@ -248,6 +251,10 @@
 	ipipe_root_domain->irqs[IPIPE_SERVICE_IPI2].control &= ~IPIPE_SYSTEM_MASK;
 	ipipe_root_domain->irqs[IPIPE_SERVICE_IPI3].control &= ~IPIPE_SYSTEM_MASK;
 #endif	/* CONFIG_X86_LOCAL_APIC */
+
+#ifdef CONFIG_KGDB
+	kgdb_catch_domain(ipipe_root_domain);
+#endif
 }
 
 static inline void __fixup_if(struct pt_regs *regs)
Index: linux-2.6.15.3-kgdb/arch/i386/kernel/kgdb.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/arch/i386/kernel/kgdb.c	2006-04-08 04:54:36.000000000 +0200
+++ linux-2.6.15.3-kgdb/arch/i386/kernel/kgdb.c	2006-04-08 11:01:52.000000000 +0200
@@ -362,3 +362,22 @@
 	.flags = KGDB_HW_BREAKPOINT,
 };
 
+#ifdef CONFIG_IPIPE
+int kgdb_catch_debug(unsigned event, struct ipipe_domain *ipd, void *data)
+{
+	struct pt_regs *regs = (struct pt_regs *)data;
+
+	return !kgdb_handle_exception(event, SIGTRAP, -1, regs);
+}
+
+void kgdb_catch_domain(struct ipipe_domain *ipd)
+{
+	ipipe_catch_event(ipd, 1, kgdb_catch_debug);
+	ipipe_catch_event(ipd, 3, kgdb_catch_debug);
+}
+
+int kgdb_catch_event_allowed(unsigned event)
+{
+	return ((event != 1) && (event != 3));
+}
+#endif /* CONFIG_IPIPE */

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Xenomai-core] kgdb over ipipe

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 1606 bytes --]

Jan Kiszka wrote:
> Hi,
> 
> this is the preliminary, though already usable result of my recent
> effort to extend the tool situation for Xenomai: A kgdb patch series for
> 2.6.15 on x86. It already works quite well but likely does not yet catch
> all fatal scenarios (e.g. page faults in the Xenomai domain).
> 

And here comes another revision (prepare patch remains unmodified).

It gets closer to what Philippe also just suggested in the original
thread: hook KGDB into I-pipe in favour of registering a dedicated
domain. The latter approach modifies the I-pipe state in a way which may
blur the picture of I-pipe itself to the debugger. This revision hooks
exception events into the I-pipe core so that they are delivered the
normal way when the root domain is active, but get catched early for
higher domains like Xenomai. I'm just not sure about the best way to
handle the serial line IRQ. Philippe, do you see problems with current
approach? Should we better hook into __ipipe_handle_irq (which would
make things more complicated, I'm afraid)?

In contrast to the first version, exceptions happening in the Xenomai
domain now also get reported to KGDB. Debugging mostly works fine, I'm
just facing unknown problems with intercepting and then continuing
kernel-only RT threads. KGDB sometimes reports "E22" back in this case,
but always locks up. Maybe it gets confused by the fact the there is no
Linux task behind Xenomai kernel threads? I tested this by putting a
breakpoint into xnpod_suspend_thread and running latency in mode 0 and
1. 0 works fine, 1 not.

Jan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: kgdb-ipipe.patch --]
[-- Type: text/x-patch; name="kgdb-ipipe.patch", Size: 3641 bytes --]

Index: linux-2.6.15.3-kgdb/kernel/kgdb.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/kernel/kgdb.c
+++ linux-2.6.15.3-kgdb/kernel/kgdb.c
@@ -740,7 +740,7 @@ static void kgdb_wait(struct pt_regs *re
 	unsigned long flags;
 	int processor;
 
-	local_irq_save(flags);
+	local_irq_save_hw(flags);
 	processor = smp_processor_id();
 	kgdb_info[processor].debuggerinfo = regs;
 	kgdb_info[processor].task = current;
@@ -770,7 +770,7 @@ static void kgdb_wait(struct pt_regs *re
 	/* Signal the master processor that we are done */
 	atomic_set(&procindebug[processor], 0);
 	spin_unlock(&slavecpulocks[processor]);
-	local_irq_restore(flags);
+	local_irq_restore_hw(flags);
 }
 #endif
 
@@ -1033,7 +1033,7 @@ int kgdb_handle_exception(int ex_vector,
 	 * Interrupts will be restored by the 'trap return' code, except when
 	 * single stepping.
 	 */
-	local_irq_save(flags);
+	local_irq_save_hw(flags);
 
 	/* Hold debugger_active */
 	procid = smp_processor_id();
@@ -1056,7 +1056,7 @@ int kgdb_handle_exception(int ex_vector,
 	if (atomic_read(&cpu_doing_single_step) != -1 &&
 	    atomic_read(&cpu_doing_single_step) != procid) {
 		atomic_set(&debugger_active, 0);
-		local_irq_restore(flags);
+		local_irq_restore_hw(flags);
 		goto acquirelock;
 	}
 
@@ -1556,7 +1556,7 @@ int kgdb_handle_exception(int ex_vector,
 kgdb_restore:
 	/* Free debugger_active */
 	atomic_set(&debugger_active, 0);
-	local_irq_restore(flags);
+	local_irq_restore_hw(flags);
 
 	return error;
 }
@@ -1925,9 +1925,9 @@ static int kgdb_notify_reboot(struct not
 	if (!kgdb_connected || atomic_read(&debugger_active) != 0)
 		return 0;
 	if ((code == SYS_RESTART) || (code == SYS_HALT) || (code == SYS_POWER_OFF)){
-		local_irq_save(flags);
+		local_irq_save_hw(flags);
 		put_packet("X00");
-		local_irq_restore(flags);
+		local_irq_restore_hw(flags);
 	}
 	return NOTIFY_DONE;
 }		
@@ -1942,9 +1942,9 @@ void kgdb_console_write(struct console *
 	if (!kgdb_connected || atomic_read(&debugger_active) != 0)
 		return;
 
-	local_irq_save(flags);
+	local_irq_save_hw(flags);
 	kgdb_msg_write(s, count);
-	local_irq_restore(flags);
+	local_irq_restore_hw(flags);
 }
 
 static struct console kgdbcons = {
Index: linux-2.6.15.3-kgdb/drivers/serial/8250_kgdb.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/drivers/serial/8250_kgdb.c
+++ linux-2.6.15.3-kgdb/drivers/serial/8250_kgdb.c
@@ -301,6 +301,10 @@ static void __init kgdb8250_late_init(vo
 			"GDB-stub", current_port) < 0)
 		printk(KERN_ERR "KGDB failed to request the serial IRQ (%d)\n",
 		       current_port->irq);
+#ifdef CONFIG_IPIPE
+	ipipe_control_irq(current_port->irq, 0,
+			IPIPE_HANDLE_MASK|IPIPE_STICKY_MASK|IPIPE_SYSTEM_MASK);
+#endif /* CONFIG_IPIPE */
 }
 
 static __init int kgdb_init_io(void)
Index: linux-2.6.15.3-kgdb/lib/Kconfig.debug
===================================================================
--- linux-2.6.15.3-kgdb.orig/lib/Kconfig.debug
+++ linux-2.6.15.3-kgdb/lib/Kconfig.debug
@@ -250,7 +250,7 @@ choice
 
 config KGDB_ONLY_MODULES
 	bool "KGDB: Use only kernel modules for I/O"
-	depends on MODULES
+	depends on MODULES && !IPIPE
 	help
 	  Use only kernel modules to configure KGDB I/O after the
 	  kernel is booted.
@@ -295,7 +295,7 @@ config KGDB_SIBYTE
 endchoice
 
 config KGDBOE
-	tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE
+	tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE && !IPIPE
 	depends on m && KGDB
 	select NETPOLL
 	select NETPOLL_TRAP

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: kgdb-ipipe-x86.patch --]
[-- Type: text/x-patch; name="kgdb-ipipe-x86.patch", Size: 3486 bytes --]

Index: linux-2.6.15.3-kgdb/arch/i386/kernel/entry.S
===================================================================
--- linux-2.6.15.3-kgdb.orig/arch/i386/kernel/entry.S
+++ linux-2.6.15.3-kgdb/arch/i386/kernel/entry.S
@@ -194,7 +194,7 @@ VM_MASK		= 0x00020000
 .previous
 
 
-ENTRY(ret_from_fork)
+KPROBE_ENTRY(ret_from_fork)
 	STI_COND_HW
 	pushl %eax
 	call schedule_tail
@@ -582,7 +582,7 @@ ENTRY(simd_coprocessor_error)
 	PUSH_XCODE(do_simd_coprocessor_error)
 	jmp error_code
 
-ENTRY(device_not_available)
+KPROBE_ENTRY(device_not_available)
 	pushl $-1			# mark this as an int
 	SAVE_ALL
 	DIVERT_EXCEPTION(device_not_available)
@@ -767,7 +767,7 @@ ENTRY(machine_check)
 	jmp error_code
 #endif
 
-ENTRY(spurious_interrupt_bug)
+KPROBE_ENTRY(spurious_interrupt_bug)
 	pushl $0
 	PUSH_XCODE(do_spurious_interrupt_bug)
 	jmp error_code
Index: linux-2.6.15.3-kgdb/arch/i386/kernel/ipipe-root.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/arch/i386/kernel/ipipe-root.c
+++ linux-2.6.15.3-kgdb/arch/i386/kernel/ipipe-root.c
@@ -34,6 +34,9 @@
 #include <asm/irq.h>
 #include <asm/desc.h>
 #include <asm/io.h>
+#ifdef CONFIG_KGDB
+#include <linux/kgdb.h>
+#endif /* CONFIG_KGDB */
 #ifdef CONFIG_X86_LOCAL_APIC
 #include <asm/tlbflush.h>
 #include <asm/fixmap.h>
@@ -427,8 +430,44 @@ static __ipipe_exptr __ipipe_std_extable
 	[ex_do_iret_error] = &do_iret_error,
 };
 
+#ifdef CONFIG_KGDB
+static int __ipipe_xlate_signo[] = {
+
+	[ex_do_divide_error] = SIGFPE,
+	[ex_do_debug] = SIGTRAP,
+	[2] = -1,
+	[ex_do_int3] = SIGTRAP,
+	[ex_do_overflow] = SIGSEGV,
+	[ex_do_bounds] = SIGSEGV,
+	[ex_do_invalid_op] = SIGILL,
+	[ex_device_not_available] = -1,
+	[8] = -1,
+	[ex_do_coprocessor_segment_overrun] = SIGFPE,
+	[ex_do_invalid_TSS] = SIGSEGV,
+	[ex_do_segment_not_present] = SIGBUS,
+	[ex_do_stack_segment] = SIGBUS,
+	[ex_do_general_protection] = SIGSEGV,
+	[ex_do_page_fault] = SIGSEGV,
+	[ex_do_spurious_interrupt_bug] = -1,
+	[ex_do_coprocessor_error] = -1,
+	[ex_do_alignment_check] = SIGBUS,
+	[ex_machine_check_vector] = -1,
+	[ex_do_simd_coprocessor_error] = -1,
+	[20 ... 31] = -1,
+	[ex_do_iret_error] = SIGSEGV,
+};
+#endif /* CONFIG_KGDB */
+
 fastcall int __ipipe_handle_exception(struct pt_regs *regs, long error_code, int vector)
 {
+#ifdef CONFIG_KGDB
+	/* catch exception KGDB is interested in over non-root domains */
+	if ((ipipe_current_domain != ipipe_root_domain) &&
+	    (__ipipe_xlate_signo[vector] >= 0) &&
+	    !kgdb_handle_exception(vector, __ipipe_xlate_signo[vector], error_code, regs))
+		return 1;
+#endif /* CONFIG_KGDB */
+
 	if (!__ipipe_event_pipelined_p(vector) ||
 	    __ipipe_dispatch_event(vector,regs) == 0) {
 		__ipipe_exptr handler = __ipipe_std_extable[vector];
@@ -442,6 +481,19 @@ fastcall int __ipipe_handle_exception(st
 
 fastcall int __ipipe_divert_exception(struct pt_regs *regs, int vector)
 {
+#ifdef CONFIG_KGDB
+	/* catch int1 and int3 over non-root domains */
+	if ((ipipe_current_domain != ipipe_root_domain) &&
+	    (vector != ex_device_not_available)) {
+		unsigned int condition = 0;
+
+		if (vector == 1)
+			get_debugreg(condition, 6);
+		if (!kgdb_handle_exception(vector, SIGTRAP, condition, regs))
+			return 1;
+	}
+#endif /* CONFIG_KGDB */
+
 	if (__ipipe_event_pipelined_p(vector) &&
 	    __ipipe_dispatch_event(vector,regs) != 0)
 		return 1;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Adeos-main] Re: [Xenomai-core] kgdb over ipipe

[Philippe Gerum]

Jan Kiszka wrote:
> Jan Kiszka wrote:
> 
>>Hi,
>>
>>this is the preliminary, though already usable result of my recent
>>effort to extend the tool situation for Xenomai: A kgdb patch series for
>>2.6.15 on x86. It already works quite well but likely does not yet catch
>>all fatal scenarios (e.g. page faults in the Xenomai domain).
>>
> 
> 
> And here comes another revision (prepare patch remains unmodified).
> 
> It gets closer to what Philippe also just suggested in the original
> thread: hook KGDB into I-pipe in favour of registering a dedicated
> domain. The latter approach modifies the I-pipe state in a way which may
> blur the picture of I-pipe itself to the debugger. This revision hooks
> exception events into the I-pipe core so that they are delivered the
> normal way when the root domain is active, but get catched early for
> higher domains like Xenomai. I'm just not sure about the best way to
> handle the serial line IRQ. Philippe, do you see problems with current
> approach? Should we better hook into __ipipe_handle_irq (which would
> make things more complicated, I'm afraid)?
> 

The current approach works fine unless a runaway thread goes wild with 
interrupts disabled (i.e. stall bit set) in the root stage or in any 
higher priority domain regardless of the root domain state, in which 
case the serial IRQ won't make it through the pipeline to KGDB.

> In contrast to the first version, exceptions happening in the Xenomai
> domain now also get reported to KGDB. Debugging mostly works fine, I'm
> just facing unknown problems with intercepting and then continuing
> kernel-only RT threads. KGDB sometimes reports "E22" back in this case,
> but always locks up. Maybe it gets confused by the fact the there is no
> Linux task behind Xenomai kernel threads? I tested this by putting a
> breakpoint into xnpod_suspend_thread and running latency in mode 0 and
> 1. 0 works fine, 1 not.
> 

KGDB is relying on "current", so it's reading garbage over Xenomai's 
kernel threads.

-- 

Philippe.

Re: [Adeos-main] Re: [Xenomai-core] kgdb over ipipe

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 3051 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Jan Kiszka wrote:
>>
>>> Hi,
>>>
>>> this is the preliminary, though already usable result of my recent
>>> effort to extend the tool situation for Xenomai: A kgdb patch series for
>>> 2.6.15 on x86. It already works quite well but likely does not yet catch
>>> all fatal scenarios (e.g. page faults in the Xenomai domain).
>>>
>>
>>
>> And here comes another revision (prepare patch remains unmodified).
>>
>> It gets closer to what Philippe also just suggested in the original
>> thread: hook KGDB into I-pipe in favour of registering a dedicated
>> domain. The latter approach modifies the I-pipe state in a way which may
>> blur the picture of I-pipe itself to the debugger. This revision hooks
>> exception events into the I-pipe core so that they are delivered the
>> normal way when the root domain is active, but get catched early for
>> higher domains like Xenomai. I'm just not sure about the best way to
>> handle the serial line IRQ. Philippe, do you see problems with current
>> approach? Should we better hook into __ipipe_handle_irq (which would
>> make things more complicated, I'm afraid)?
>>
> 
> The current approach works fine unless a runaway thread goes wild with
> interrupts disabled (i.e. stall bit set) in the root stage or in any
> higher priority domain regardless of the root domain state, in which
> case the serial IRQ won't make it through the pipeline to KGDB.

But catching this would mean to change the behaviour of ipipe regarding
the highest priority domain from hard to soft masking of IRQs. Hmm,
should be made at least optional to catch scenarios where this change
makes bugs move (away...).

Would be the easiest way to achieve this to register a dummy domain
ahead of Xenomai (i.e. with higher prio)? Additionally, we would have to
modify the IRQ pipeline in a way that, e.g., some flag makes an IRQ not
only sticky but also "non-maskable" (I would make this also an option to
avoid overhead for non-debugging scenarios).

Well, not yet an essential feature for me, because we still have the NMI
watchdog and the option to spread breakpoints. But we should keep it in
mind.

> 
>> In contrast to the first version, exceptions happening in the Xenomai
>> domain now also get reported to KGDB. Debugging mostly works fine, I'm
>> just facing unknown problems with intercepting and then continuing
>> kernel-only RT threads. KGDB sometimes reports "E22" back in this case,
>> but always locks up. Maybe it gets confused by the fact the there is no
>> Linux task behind Xenomai kernel threads? I tested this by putting a
>> breakpoint into xnpod_suspend_thread and running latency in mode 0 and
>> 1. 0 works fine, 1 not.
>>
> 
> KGDB is relying on "current", so it's reading garbage over Xenomai's
> kernel threads.
> 

Attached is an improved version of the kgdb-ipipe.patch that copes with
this situation by mapping invalid currents to init_task. Kernel threads
are nicely debuggable now. =8)

Jan

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: kgdb-ipipe.patch --]
[-- Type: text/x-patch; name="kgdb-ipipe.patch", Size: 7148 bytes --]

Index: linux-2.6.15.3-kgdb/kernel/kgdb.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/kernel/kgdb.c
+++ linux-2.6.15.3-kgdb/kernel/kgdb.c
@@ -49,6 +49,15 @@
 #include <linux/console.h>
 #include <asm/byteorder.h>
 
+#ifdef CONFIG_XENOMAI
+#include <xenomai/nucleus/pod.h>
+#define CURRENT_VALID		(!nkpod || xnpod_userspace_p())
+#define SAFE_CURRENT		(CURRENT_VALID ? current : &init_task)
+#else /* !CONFIG_XENOMAI */
+#define CURRENT_VALID		1
+#define SAFE_CURRENT		current
+#endif
+
 extern int pid_max;
 extern int pidhash_init_done;
 
@@ -740,10 +749,10 @@ static void kgdb_wait(struct pt_regs *re
 	unsigned long flags;
 	int processor;
 
-	local_irq_save(flags);
+	local_irq_save_hw(flags);
 	processor = smp_processor_id();
 	kgdb_info[processor].debuggerinfo = regs;
-	kgdb_info[processor].task = current;
+	kgdb_info[processor].task = SAFE_CURRENT;
 	atomic_set(&procindebug[processor], 1);
 	atomic_set(&kgdb_sync_softlockup[smp_processor_id()],1);
 
@@ -770,7 +779,7 @@ static void kgdb_wait(struct pt_regs *re
 	/* Signal the master processor that we are done */
 	atomic_set(&procindebug[processor], 0);
 	spin_unlock(&slavecpulocks[processor]);
-	local_irq_restore(flags);
+	local_irq_restore_hw(flags);
 }
 #endif
 
@@ -821,7 +830,7 @@ int kgdb_activate_sw_breakpoints(void)
 			return error;
 
 		if (CACHE_FLUSH_IS_SAFE) {
-			if (current->mm && addr < TASK_SIZE)
+			if (CURRENT_VALID && current->mm && addr < TASK_SIZE)
 				flush_cache_range(current->mm->mmap_cache, 
 						addr, addr + BREAK_INSTR_SIZE);
 			else
@@ -884,7 +893,7 @@ int kgdb_deactivate_sw_breakpoints(void)
 					kgdb_break[i].saved_instr)))
 			return error;
 
-		if (CACHE_FLUSH_IS_SAFE && current->mm &&
+		if (CACHE_FLUSH_IS_SAFE && CURRENT_VALID && current->mm &&
 				addr < TASK_SIZE)
 			flush_cache_range(current->mm->mmap_cache,
 					addr, addr + BREAK_INSTR_SIZE);
@@ -1033,7 +1042,7 @@ int kgdb_handle_exception(int ex_vector,
 	 * Interrupts will be restored by the 'trap return' code, except when
 	 * single stepping.
 	 */
-	local_irq_save(flags);
+	local_irq_save_hw(flags);
 
 	/* Hold debugger_active */
 	procid = smp_processor_id();
@@ -1056,7 +1065,7 @@ int kgdb_handle_exception(int ex_vector,
 	if (atomic_read(&cpu_doing_single_step) != -1 &&
 	    atomic_read(&cpu_doing_single_step) != procid) {
 		atomic_set(&debugger_active, 0);
-		local_irq_restore(flags);
+		local_irq_restore_hw(flags);
 		goto acquirelock;
 	}
 
@@ -1069,7 +1078,7 @@ int kgdb_handle_exception(int ex_vector,
 		goto kgdb_restore;
 
 	kgdb_info[processor].debuggerinfo = linux_regs;
-	kgdb_info[processor].task = current;
+	kgdb_info[processor].task = SAFE_CURRENT;
 
 	kgdb_disable_hw_debug(linux_regs);
 
@@ -1121,7 +1130,7 @@ int kgdb_handle_exception(int ex_vector,
 		*ptr++ = hexchars[(signo >> 4) % 16];
 		*ptr++ = hexchars[signo % 16];
 		ptr += strlen(strcpy(ptr, "thread:"));
-		int_to_threadref(&thref, shadow_pid(current->pid));
+		int_to_threadref(&thref, shadow_pid(SAFE_CURRENT->pid));
 		ptr = pack_threadid(ptr, &thref);
 		*ptr++ = ';';
 
@@ -1213,7 +1222,7 @@ int kgdb_handle_exception(int ex_vector,
 			kgdb_hex2mem(&remcom_in_buffer[1], (char *)gdb_regs,
 				     NUMREGBYTES);
 
-			if (kgdb_usethread && kgdb_usethread != current)
+			if (kgdb_usethread && kgdb_usethread != SAFE_CURRENT)
 				error_packet(remcom_out_buffer, -EINVAL);
 			else {
 				gdb_regs_to_regs(gdb_regs, linux_regs);
@@ -1334,7 +1343,7 @@ int kgdb_handle_exception(int ex_vector,
 				/* Current thread id */
 				strcpy(remcom_out_buffer, "QC");
 
-				threadid = shadow_pid(current->pid);
+				threadid = shadow_pid(SAFE_CURRENT->pid);
 
 				int_to_threadref(&thref, threadid);
 				pack_threadid(remcom_out_buffer + 2, &thref);
@@ -1488,7 +1497,7 @@ int kgdb_handle_exception(int ex_vector,
 			break;
 		case 'c':
 		case 's':
-			if (kgdb_contthread && kgdb_contthread != current) {
+			if (kgdb_contthread && kgdb_contthread != SAFE_CURRENT) {
 				/* Can't switch threads in kgdb */
 				error_packet(remcom_out_buffer, -EINVAL);
 				break;
@@ -1556,7 +1565,7 @@ int kgdb_handle_exception(int ex_vector,
 kgdb_restore:
 	/* Free debugger_active */
 	atomic_set(&debugger_active, 0);
-	local_irq_restore(flags);
+	local_irq_restore_hw(flags);
 
 	return error;
 }
@@ -1925,9 +1934,9 @@ static int kgdb_notify_reboot(struct not
 	if (!kgdb_connected || atomic_read(&debugger_active) != 0)
 		return 0;
 	if ((code == SYS_RESTART) || (code == SYS_HALT) || (code == SYS_POWER_OFF)){
-		local_irq_save(flags);
+		local_irq_save_hw(flags);
 		put_packet("X00");
-		local_irq_restore(flags);
+		local_irq_restore_hw(flags);
 	}
 	return NOTIFY_DONE;
 }		
@@ -1942,9 +1951,9 @@ void kgdb_console_write(struct console *
 	if (!kgdb_connected || atomic_read(&debugger_active) != 0)
 		return;
 
-	local_irq_save(flags);
+	local_irq_save_hw(flags);
 	kgdb_msg_write(s, count);
-	local_irq_restore(flags);
+	local_irq_restore_hw(flags);
 }
 
 static struct console kgdbcons = {
Index: linux-2.6.15.3-kgdb/drivers/serial/8250_kgdb.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/drivers/serial/8250_kgdb.c
+++ linux-2.6.15.3-kgdb/drivers/serial/8250_kgdb.c
@@ -301,6 +301,10 @@ static void __init kgdb8250_late_init(vo
 			"GDB-stub", current_port) < 0)
 		printk(KERN_ERR "KGDB failed to request the serial IRQ (%d)\n",
 		       current_port->irq);
+#ifdef CONFIG_IPIPE
+	ipipe_control_irq(current_port->irq, 0,
+			IPIPE_HANDLE_MASK|IPIPE_STICKY_MASK|IPIPE_SYSTEM_MASK);
+#endif /* CONFIG_IPIPE */
 }
 
 static __init int kgdb_init_io(void)
Index: linux-2.6.15.3-kgdb/lib/Kconfig.debug
===================================================================
--- linux-2.6.15.3-kgdb.orig/lib/Kconfig.debug
+++ linux-2.6.15.3-kgdb/lib/Kconfig.debug
@@ -250,7 +250,7 @@ choice
 
 config KGDB_ONLY_MODULES
 	bool "KGDB: Use only kernel modules for I/O"
-	depends on MODULES
+	depends on MODULES && !IPIPE
 	help
 	  Use only kernel modules to configure KGDB I/O after the
 	  kernel is booted.
@@ -295,7 +295,7 @@ config KGDB_SIBYTE
 endchoice
 
 config KGDBOE
-	tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE
+	tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE && !IPIPE
 	depends on m && KGDB
 	select NETPOLL
 	select NETPOLL_TRAP
Index: linux-2.6.15.3-kgdb/kernel/Makefile
===================================================================
--- linux-2.6.15.3-kgdb.orig/kernel/Makefile
+++ linux-2.6.15.3-kgdb/kernel/Makefile
@@ -35,6 +35,10 @@ obj-$(CONFIG_SECCOMP) += seccomp.o
 obj-$(CONFIG_RCU_TORTURE_TEST) += rcutorture.o
 obj-$(CONFIG_IPIPE) += ipipe/
 
+ifeq ($(CONFIG_XENOMAI),y)
+EXTRA_CFLAGS += -Iinclude/xenomai
+endif
+
 ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
 # According to Alan Modra <alan@domain.hid>, the -fno-omit-frame-pointer is
 # needed for x86 only.  Why this used to be enabled for all architectures is beyond

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Adeos-main] Re: [Xenomai-core] kgdb over ipipe

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Jan Kiszka wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>this is the preliminary, though already usable result of my recent
>>>>effort to extend the tool situation for Xenomai: A kgdb patch series for
>>>>2.6.15 on x86. It already works quite well but likely does not yet catch
>>>>all fatal scenarios (e.g. page faults in the Xenomai domain).
>>>>
>>>
>>>
>>>And here comes another revision (prepare patch remains unmodified).
>>>
>>>It gets closer to what Philippe also just suggested in the original
>>>thread: hook KGDB into I-pipe in favour of registering a dedicated
>>>domain. The latter approach modifies the I-pipe state in a way which may
>>>blur the picture of I-pipe itself to the debugger. This revision hooks
>>>exception events into the I-pipe core so that they are delivered the
>>>normal way when the root domain is active, but get catched early for
>>>higher domains like Xenomai. I'm just not sure about the best way to
>>>handle the serial line IRQ. Philippe, do you see problems with current
>>>approach? Should we better hook into __ipipe_handle_irq (which would
>>>make things more complicated, I'm afraid)?
>>>
>>
>>The current approach works fine unless a runaway thread goes wild with
>>interrupts disabled (i.e. stall bit set) in the root stage or in any
>>higher priority domain regardless of the root domain state, in which
>>case the serial IRQ won't make it through the pipeline to KGDB.
> 
> 
> But catching this would mean to change the behaviour of ipipe regarding
> the highest priority domain from hard to soft masking of IRQs. Hmm,
> should be made at least optional to catch scenarios where this change
> makes bugs move (away...).
> 
> Would be the easiest way to achieve this to register a dummy domain
> ahead of Xenomai (i.e. with higher prio)?

This would be the theoretically "normal" way to do this, but this comes 
with the undesirable side-effect of losing the hw masking of interrupts 
for the Xenomai domain, since you stack another domain on top.

  Additionally, we would have to
> modify the IRQ pipeline in a way that, e.g., some flag makes an IRQ not
> only sticky but also "non-maskable" (I would make this also an option to
> avoid overhead for non-debugging scenarios).
> 

By non-maskable, you mean at PIC-level?

> Well, not yet an essential feature for me, because we still have the NMI
> watchdog and the option to spread breakpoints. But we should keep it in
> mind.
> 
> 
>>>In contrast to the first version, exceptions happening in the Xenomai
>>>domain now also get reported to KGDB. Debugging mostly works fine, I'm
>>>just facing unknown problems with intercepting and then continuing
>>>kernel-only RT threads. KGDB sometimes reports "E22" back in this case,
>>>but always locks up. Maybe it gets confused by the fact the there is no
>>>Linux task behind Xenomai kernel threads? I tested this by putting a
>>>breakpoint into xnpod_suspend_thread and running latency in mode 0 and
>>>1. 0 works fine, 1 not.
>>>
>>
>>KGDB is relying on "current", so it's reading garbage over Xenomai's
>>kernel threads.
>>
> 
> 
> Attached is an improved version of the kgdb-ipipe.patch that copes with
> this situation by mapping invalid currents to init_task. Kernel threads
> are nicely debuggable now. =8)
> 

Ok, queued.

-- 

Philippe.

Re: [Adeos-main] Re: [Xenomai-core] kgdb over ipipe

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 3751 bytes --]

Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>> Jan Kiszka wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> this is the preliminary, though already usable result of my recent
>>>>> effort to extend the tool situation for Xenomai: A kgdb patch
>>>>> series for
>>>>> 2.6.15 on x86. It already works quite well but likely does not yet
>>>>> catch
>>>>> all fatal scenarios (e.g. page faults in the Xenomai domain).
>>>>>
>>>>
>>>>
>>>> And here comes another revision (prepare patch remains unmodified).
>>>>
>>>> It gets closer to what Philippe also just suggested in the original
>>>> thread: hook KGDB into I-pipe in favour of registering a dedicated
>>>> domain. The latter approach modifies the I-pipe state in a way which
>>>> may
>>>> blur the picture of I-pipe itself to the debugger. This revision hooks
>>>> exception events into the I-pipe core so that they are delivered the
>>>> normal way when the root domain is active, but get catched early for
>>>> higher domains like Xenomai. I'm just not sure about the best way to
>>>> handle the serial line IRQ. Philippe, do you see problems with current
>>>> approach? Should we better hook into __ipipe_handle_irq (which would
>>>> make things more complicated, I'm afraid)?
>>>>
>>>
>>> The current approach works fine unless a runaway thread goes wild with
>>> interrupts disabled (i.e. stall bit set) in the root stage or in any
>>> higher priority domain regardless of the root domain state, in which
>>> case the serial IRQ won't make it through the pipeline to KGDB.
>>
>>
>> But catching this would mean to change the behaviour of ipipe regarding
>> the highest priority domain from hard to soft masking of IRQs. Hmm,
>> should be made at least optional to catch scenarios where this change
>> makes bugs move (away...).
>>
>> Would be the easiest way to achieve this to register a dummy domain
>> ahead of Xenomai (i.e. with higher prio)?
> 
> This would be the theoretically "normal" way to do this, but this comes
> with the undesirable side-effect of losing the hw masking of interrupts
> for the Xenomai domain, since you stack another domain on top.
> 
>  Additionally, we would have to
>> modify the IRQ pipeline in a way that, e.g., some flag makes an IRQ not
>> only sticky but also "non-maskable" (I would make this also an option to
>> avoid overhead for non-debugging scenarios).
>>
> 
> By non-maskable, you mean at PIC-level?

Nope, at software-level. I mean that such IRQs would always be passed
down the pipeline, even through stalled domains.

> 
>> Well, not yet an essential feature for me, because we still have the NMI
>> watchdog and the option to spread breakpoints. But we should keep it in
>> mind.
>>
>>
>>>> In contrast to the first version, exceptions happening in the Xenomai
>>>> domain now also get reported to KGDB. Debugging mostly works fine, I'm
>>>> just facing unknown problems with intercepting and then continuing
>>>> kernel-only RT threads. KGDB sometimes reports "E22" back in this case,
>>>> but always locks up. Maybe it gets confused by the fact the there is no
>>>> Linux task behind Xenomai kernel threads? I tested this by putting a
>>>> breakpoint into xnpod_suspend_thread and running latency in mode 0 and
>>>> 1. 0 works fine, 1 not.
>>>>
>>>
>>> KGDB is relying on "current", so it's reading garbage over Xenomai's
>>> kernel threads.
>>>
>>
>>
>> Attached is an improved version of the kgdb-ipipe.patch that copes with
>> this situation by mapping invalid currents to init_task. Kernel threads
>> are nicely debuggable now. =8)
>>
> 
> Ok, queued.
> 

As an add-on patch like the tracer?

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Adeos-main] Re: [Xenomai-core] kgdb over ipipe

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>>Philippe Gerum wrote:
>>>
>>>
>>>>Jan Kiszka wrote:
>>>>
>>>>
>>>>>Jan Kiszka wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>this is the preliminary, though already usable result of my recent
>>>>>>effort to extend the tool situation for Xenomai: A kgdb patch
>>>>>>series for
>>>>>>2.6.15 on x86. It already works quite well but likely does not yet
>>>>>>catch
>>>>>>all fatal scenarios (e.g. page faults in the Xenomai domain).
>>>>>>
>>>>>
>>>>>
>>>>>And here comes another revision (prepare patch remains unmodified).
>>>>>
>>>>>It gets closer to what Philippe also just suggested in the original
>>>>>thread: hook KGDB into I-pipe in favour of registering a dedicated
>>>>>domain. The latter approach modifies the I-pipe state in a way which
>>>>>may
>>>>>blur the picture of I-pipe itself to the debugger. This revision hooks
>>>>>exception events into the I-pipe core so that they are delivered the
>>>>>normal way when the root domain is active, but get catched early for
>>>>>higher domains like Xenomai. I'm just not sure about the best way to
>>>>>handle the serial line IRQ. Philippe, do you see problems with current
>>>>>approach? Should we better hook into __ipipe_handle_irq (which would
>>>>>make things more complicated, I'm afraid)?
>>>>>
>>>>
>>>>The current approach works fine unless a runaway thread goes wild with
>>>>interrupts disabled (i.e. stall bit set) in the root stage or in any
>>>>higher priority domain regardless of the root domain state, in which
>>>>case the serial IRQ won't make it through the pipeline to KGDB.
>>>
>>>
>>>But catching this would mean to change the behaviour of ipipe regarding
>>>the highest priority domain from hard to soft masking of IRQs. Hmm,
>>>should be made at least optional to catch scenarios where this change
>>>makes bugs move (away...).
>>>
>>>Would be the easiest way to achieve this to register a dummy domain
>>>ahead of Xenomai (i.e. with higher prio)?
>>
>>This would be the theoretically "normal" way to do this, but this comes
>>with the undesirable side-effect of losing the hw masking of interrupts
>>for the Xenomai domain, since you stack another domain on top.
>>
>> Additionally, we would have to
>>
>>>modify the IRQ pipeline in a way that, e.g., some flag makes an IRQ not
>>>only sticky but also "non-maskable" (I would make this also an option to
>>>avoid overhead for non-debugging scenarios).
>>>
>>
>>By non-maskable, you mean at PIC-level?
> 
> 
> Nope, at software-level. I mean that such IRQs would always be passed
> down the pipeline, even through stalled domains.
> 

Can't do that. This would wreck the entire Adeos logic.

> 
>>>Well, not yet an essential feature for me, because we still have the NMI
>>>watchdog and the option to spread breakpoints. But we should keep it in
>>>mind.
>>>
>>>
>>>
>>>>>In contrast to the first version, exceptions happening in the Xenomai
>>>>>domain now also get reported to KGDB. Debugging mostly works fine, I'm
>>>>>just facing unknown problems with intercepting and then continuing
>>>>>kernel-only RT threads. KGDB sometimes reports "E22" back in this case,
>>>>>but always locks up. Maybe it gets confused by the fact the there is no
>>>>>Linux task behind Xenomai kernel threads? I tested this by putting a
>>>>>breakpoint into xnpod_suspend_thread and running latency in mode 0 and
>>>>>1. 0 works fine, 1 not.
>>>>>
>>>>
>>>>KGDB is relying on "current", so it's reading garbage over Xenomai's
>>>>kernel threads.
>>>>
>>>
>>>
>>>Attached is an improved version of the kgdb-ipipe.patch that copes with
>>>this situation by mapping invalid currents to init_task. Kernel threads
>>>are nicely debuggable now. =8)
>>>
>>
>>Ok, queued.
>>
> 
> 
> As an add-on patch like the tracer?
> 

Don't know yet. The bottom line is that changes which are independent 
from the KGDB patch could go to the mainline Adeos patch since they are 
few and small, except for entirely new files which would be maintained 
separately.

-- 

Philippe.