Hi Jan,

Based on your previous work, here is a set of patches coupling KGDB and 
the I-pipe. Basically, I've attempted to shrink the extra patches needed 
against the original KGDB + I-pipe ones to the bare minimum. This has 
been obtained by having the I-pipe provide ipipe_current_safe(), and 
drastically reduce the amount of fiddling with smp_processor_id().

The key difference with the former implementation is that a domain (e.g. 
Xenomai) is now expected to tell the I-pipe when it's switching to a 
non-Linux stack, and the I-pipe makes good use of this information to 
return the proper "current" value when asked to through 
ipipe_safe_current() from the KGDB code. The issue of swapping 
smp_processor_id() with ipipe_processor_id() has been addressed the hard 
way: smp_processor_id() is simply defined as ipipe_processor_id() when 
CONFIG_IPIPE and CONFIG_KGDB are both enabled in include/linux/smp.h. 
This approach was actually used during the old Adeos times when pipeline 
domain had their own separate stack. I take for granted that the CPU 
penalty taken in doing this is perfectly acceptable, since well, we are 
debugging after all.

Aside of the small patches attached, you will need the latest I-pipe 
1.3-05 patch for x86, adding the foreign stack notifier and the 
ipipe_safe_current() support:
http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.16-i386-1.3-05.patch

Patches should be applied in this order on a vanilla 2.6.16 kernel:

- KGDB 2.4 patch series over 2.6.16 (quilt)
- pre-kgdb-ipipe-i386.patch
- adeos-ipipe-2.6.16-i386-1.3-05.patch
- kgdb-ipipe.patch
- post-kgdb-ipipe-i386.patch

Xenomai's trunk/ should be used. Older code won't work and likely crash 
since the I-pipe would not be notified about foreign stack switches.

Now the surprise: I did not test this stuff, I mean, at all. Eh. :o)

-- 

Philippe.