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...

> 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:
> 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).


(*) Actually, that's feasible: kgdb-patched kernel inside qemu - already
done this (to find [1]), it's just a bit sloooow.


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to