Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>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
> 
> 
> This looks nice.
> 
> 
>>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.
> 
> 
> There is only one drawback: we will not be able to debug
> smp_processor_id-related bugs in ipipe/Xenomai anymore...
> 

Good point. Here is an updated patch.

> 
>>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)
> 
> 
> That's fair: leave the head banging while debugging debuggers (*) up to
> me. ;)
> 
> Will try to let this fly, likely not before the weekend.
> 
> BTW, there is one pending issue of gcc-4.1 which popped up under kgdb,
> see [1] (also for a workaround).
> 

Mm, I'll keep on working with gcc3.4 and 8k stacks on x86 then.

> Jan
> 
> 
> (*) Actually, that's feasible: kgdb-patched kernel inside qemu - already
> done this (to find [1]), it's just a bit sloooow.
> 
> [1]http://sourceforge.net/mailarchive/forum.php?thread_id=10452132&forum_id=5557
> 


-- 

Philippe.