[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: While we are at it, #define current ipipe_safe_current() /* ? */ Nope, there is the need for some special changes. If you refer to the cache flushing issue, then it would be better to actually check for foreign stacks explicitely, so that you could substitute current globally: -if (CACHE_FLUSH_IS_SAFE && current->mm && -addr < TASK_SIZE) +if (CACHE_FLUSH_IS_SAFE && !testbit(IPIPE_NOSTACK_FLAG, + &ipipe_percpu_domain[cpuid]->cpudata[cpuid].status) && +current->mm && addr < TASK_SIZE) Right - on first sight. I tried to redefine current, but the ipipe_safe_current macro requires that symbol itself, ugh. Turning ipipe_safe_current into a static inline doesn't work due to circular dependencies on linux/sched.h. So I guess it's best to keep it as it is (though kgdb-ipipe.patch would have become really cute). Ack. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
Philippe Gerum wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >>> While we are at it, >>> #define current ipipe_safe_current() /* ? */ >> >> >> Nope, there is the need for some special changes. >> > > If you refer to the cache flushing issue, then it would be better to > actually check for foreign stacks explicitely, so that you could > substitute current globally: > > -if (CACHE_FLUSH_IS_SAFE && current->mm && > -addr < TASK_SIZE) > +if (CACHE_FLUSH_IS_SAFE && !testbit(IPIPE_NOSTACK_FLAG, > + &ipipe_percpu_domain[cpuid]->cpudata[cpuid].status) && > +current->mm && addr < TASK_SIZE) > Right - on first sight. I tried to redefine current, but the ipipe_safe_current macro requires that symbol itself, ugh. Turning ipipe_safe_current into a static inline doesn't work due to circular dependencies on linux/sched.h. So I guess it's best to keep it as it is (though kgdb-ipipe.patch would have become really cute). Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
Jan Kiszka wrote: Philippe Gerum wrote: Jan Kiszka wrote: Philippe Gerum wrote: 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. Nope that's not the point I meant. I was referring to bugs like the missing smp_processor_id patch in asm-i386/mmu_context.h. Your way makes such problems disappear once you switch on the debugger. Remember that we spotted the mmu_context issue via kgdb. Got it now. Indeed, making such kind of bugs disappear would be a very undesirable side-effect of enabling KGDB. The attached kgdb-ipipe patch (which also updates to kgdb-CVS head) addresses maintenance and smp-safeness by redefining the involved services only per source file, not kernel-wide. What's do you think about this approach? Mixed feelings. On one hand, it locally fixes the issue without masking any bugs and that's good. On the other hand, I've been bitten using this kind of tricks in earlier Adeos releases for patching printk() the same way, substituting it with spin_lock_irqsave_hw. At some point, spin_lock_irqsave became local_irq_save + spin_lock in the vanilla code, making the substitution of the former pointless, and opening a preemption hole in the code. This said, no spinlock macros are involved in the substitution you are suggesting, so there is no such risk, and in any case, the risk is confined to one file and not spread all over the place like with the raw_smp_processor_id() substitution. IOW, let's go your way. I agree that it's kind of fragile, but we need to check on kgdb updates anyway. I hope for kgdb becoming mainline one day. Then the code should stabilise (if it hasn't already), and we can track it via ipipe directly - without tricks. So far, this should help to keep efforts lower for us. While we are at it, #define current ipipe_safe_current() /* ? */ Nope, there is the need for some special changes. If you refer to the cache flushing issue, then it would be better to actually check for foreign stacks explicitely, so that you could substitute current globally: - if (CACHE_FLUSH_IS_SAFE && current->mm && - addr < TASK_SIZE) + if (CACHE_FLUSH_IS_SAFE && !testbit(IPIPE_NOSTACK_FLAG, + &ipipe_percpu_domain[cpuid]->cpudata[cpuid].status) && + current->mm && addr < TASK_SIZE) -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
Philippe Gerum wrote: > Jan Kiszka wrote: >> Philippe Gerum wrote: >> >>> 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. >>> >> >> >> Nope that's not the point I meant. I was referring to bugs like the >> missing smp_processor_id patch in asm-i386/mmu_context.h. Your way makes >> such problems disappear once you switch on the debugger. Remember that >> we spotted the mmu_context issue via kgdb. >> > > Got it now. Indeed, making such kind of bugs disappear would be a very > undesirable side-effect of enabling KGDB. > >> The attached kgdb-ipipe patch (which also updates to kgdb-CVS head) >> addresses maintenance and smp-safeness by redefining the involved >> services only per source file, not kernel-wide. What's do you think >> about this approach? >> > > Mixed feelings. On one hand, it locally fixes the issue without masking > any bugs and that's good. On the other hand, I've been bitten using this > kind of tricks in earlier Adeos releases for patching printk() the same > way, substituting it with spin_lock_irqsave_hw. At some point, > spin_lock_irqsave became local_irq_save + spin_lock in the vanilla code, > making the substitution of the former pointless, and opening a > preemption hole in the code. This said, no spinlock macros are involved > in the substitution you are suggesting, so there is no such risk, and in > any case, the risk is confined to one file and not spread all over the > place like with the raw_smp_processor_id() substitution. IOW, let's go > your way. I agree that it's kind of fragile, but we need to check on kgdb updates anyway. I hope for kgdb becoming mainline one day. Then the code should stabilise (if it hasn't already), and we can track it via ipipe directly - without tricks. So far, this should help to keep efforts lower for us. > > While we are at it, > #define current ipipe_safe_current() /* ? */ Nope, there is the need for some special changes. > >> I'm also posting two fixes for ipipe itself to 1) make kgdb work over >> SMP and 2) fix a compiler warning. >> >> This version works fine for me, at least in qemu. I tried to check SMP >> as well, but qemu obviously lacks support for NMIs raised via IPI, and >> this is used by kgdb to sync all CPUs on debugging events (vanilla kgdb >> suffers too). >> > Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
Jan Kiszka wrote: Philippe Gerum wrote: 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. Nope that's not the point I meant. I was referring to bugs like the missing smp_processor_id patch in asm-i386/mmu_context.h. Your way makes such problems disappear once you switch on the debugger. Remember that we spotted the mmu_context issue via kgdb. Got it now. Indeed, making such kind of bugs disappear would be a very undesirable side-effect of enabling KGDB. The attached kgdb-ipipe patch (which also updates to kgdb-CVS head) addresses maintenance and smp-safeness by redefining the involved services only per source file, not kernel-wide. What's do you think about this approach? Mixed feelings. On one hand, it locally fixes the issue without masking any bugs and that's good. On the other hand, I've been bitten using this kind of tricks in earlier Adeos releases for patching printk() the same way, substituting it with spin_lock_irqsave_hw. At some point, spin_lock_irqsave became local_irq_save + spin_lock in the vanilla code, making the substitution of the former pointless, and opening a preemption hole in the code. This said, no spinlock macros are involved in the substitution you are suggesting, so there is no such risk, and in any case, the risk is confined to one file and not spread all over the place like with the raw_smp_processor_id() substitution. IOW, let's go your way. While we are at it, #define current ipipe_safe_current() /* ? */ I'm also posting two fixes for ipipe itself to 1) make kgdb work over SMP and 2) fix a compiler warning. This version works fine for me, at least in qemu. I tried to check SMP as well, but qemu obviously lacks support for NMIs raised via IPI, and this is used by kgdb to sync all CPUs on debugging events (vanilla kgdb suffers too). -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
Philippe Gerum wrote:
> 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.
>
Nope that's not the point I meant. I was referring to bugs like the
missing smp_processor_id patch in asm-i386/mmu_context.h. Your way makes
such problems disappear once you switch on the debugger. Remember that
we spotted the mmu_context issue via kgdb.
The attached kgdb-ipipe patch (which also updates to kgdb-CVS head)
addresses maintenance and smp-safeness by redefining the involved
services only per source file, not kernel-wide. What's do you think
about this approach?
I'm also posting two fixes for ipipe itself to 1) make kgdb work over
SMP and 2) fix a compiler warning.
This version works fine for me, at least in qemu. I tried to check SMP
as well, but qemu obviously lacks support for NMIs raised via IPI, and
this is used by kgdb to sync all CPUs on debugging events (vanilla kgdb
suffers too).
Jan
Index: linux/kernel/kgdb.c
===
--- linux.orig/kernel/kgdb.c
+++ linux/kernel/kgdb.c
@@ -49,6 +49,15 @@
#include
#include
+#if defined(CONFIG_KGDB) && defined(CONFIG_IPIPE)
+#undef smp_processor_id
+#undef local_irq_save
+#undef local_irq_restore
+#define smp_processor_idipipe_processor_id
+#define local_irq_save local_irq_save_hw
+#define local_irq_restore local_irq_restore_hw
+#endif
+
extern int pid_max;
extern int pidhash_init_done;
@@ -743,7 +752,7 @@ static void kgdb_wait(struct pt_regs *re
local_irq_save(flags);
processor = smp_processor_id();
kgdb_info[processor].debuggerinfo = regs;
- kgdb_info[processor].task = current;
+ kgdb_info[processor].task = ipipe_safe_current();
atomic_set(&procindebug[processor], 1);
atomic_set(&kgdb_sync_softlockup[smp_processor_id()], 1);
@@ -884,8 +893,8 @@ int kgdb_deactivate_sw_breakpoints(void)
kgdb_break[i].saved_instr)))
return error;
- if (CACHE_FLUSH_IS_SAFE && current->mm &&
-addr < TASK_SIZE)
+ if (CACHE_FLUSH_IS_SAFE && ipipe_safe_current() == current &&
+current->mm && addr < TASK_SIZE)
flush_cache_range(current->mm->mmap_cache,
addr, addr + BREAK_INSTR_SIZE);
else if (CACHE_FLUSH_IS_SAFE)
@@ -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 = ipipe_safe_current();
kgdb_disable_hw_debug(linux_regs);
@@ -1121,7 +1130,8 @@ 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(ipipe_safe_current()->pid));
ptr = pack_threadid(ptr, &thref);
*ptr++ = ';';
@@ -1213,7 +1223,8 @@ 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 != ipipe_safe_current())
error_packet(remcom_out_buffer, -EINVAL);
else {
gdb_regs_to_regs(gdb_regs, linux_regs);
@@ -1334,7 +1345,8 @@ int kgdb_handle_exception(int ex_vector,
/* Current thread id */
strcpy(remcom_out_buffer, "QC");
-threadid = shadow_pid(current->pid);
+threadid =
+ shadow_pid(ipipe_safe_current()->pid);
int_to_threadref(&thref, threadid);
pack_threadid(remcom_out_buffer + 2, &thref);
@@ -1488,7 +1500,8 @@ int kgdb_handle_ex
[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
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 slw.
[1]http://sourceforge.net/mailarchive/forum.php?thread_id=10452132&forum_id=5557
--
Philippe.
--- 2.6.16-base/kernel/kgdb.c 2006-06-07 16:40:21.0 +0200
+++ 2.6.16-kgdb/kernel/kgdb.c 2006-06-07 16:43:36.0 +0200
@@ -740,10 +740,10 @@
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 = ipipe_safe_current();
atomic_set(&procindebug[processor], 1);
/* Wait till master processor goes completely into the debugger.
@@ -769,7 +769,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
@@ -883,8 +883,8 @@
kgdb_break[i].saved_instr)))
return error;
- if (CACHE_FLUSH_IS_SAFE && current->mm &&
-addr < TASK_SIZE)
+ if (CACHE_FLUSH_IS_SAFE && ipipe_safe_current() == current &&
+current->mm && addr < TASK_SIZE)
flush_cache_range(current->mm->mmap_cache,
addr, addr + BREAK_INSTR_SIZE);
else if (CACHE_FLUSH_IS_SAFE)
@@ -1032,7 +1032,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();
@@ -1055,7 +1055,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;
}
@@ -1068,7 +1068,7 @@
goto kgdb_restore;
kgdb_info[processor].debuggerinfo = linux_regs;
- kgdb_info[processor].task = current;
+ kgdb_info[processor].task = ipipe_safe_current();
kgdb_disable_hw_debug(linux_regs);
@@ -1120,7 +1120,8 @@
*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(ipipe_safe_current()->pid));
ptr = pack_threadid(ptr, &thref);
*ptr++ = ';';
@@ -1212,7 +1213,8 @@
kgdb_hex2mem(&remcom_in_buffer[1], (char *)gdb_regs,
NUMREGBYTES);
- if (kgdb_usethread && kgdb_usethread != current)
+ if (kgdb_usethread &&
+ kgdb_usethread != ipipe_sa
[Xenomai-core] Re: [PATCH] kgdb/x86 over I-pipe
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: > 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). Jan (*) Actually, that's feasible: kgdb-patched kernel inside qemu - already done this (to find [1]), it's just a bit slw. [1]http://sourceforge.net/mailarchive/forum.php?thread_id=10452132&forum_id=5557 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
