RE: [ECOS] Multi thread Debugging

[Fabrice Gautier <Fabrice_Gautier@sdesigns.com>]

Again more thoughts about that.
(Sorry if i'm filling your mailboxes)

> [...]
> If I'm not wrong in anything this means that :
> 
> 1/ The HAL_SavedRegister structure does not contain all the 
> information needed by the debugger. 

> 3/ The get_saved_context function is buggy: when the 
> saved_context member is null (means the thread switch was not 
> caused by an IRQ) it should reconstruct a valid context using 
> stack_ptr. In fact this is the HAL_THREAD_GET_SAVED_REGISTERS 
> macro that is buggy. So this is a i386 specific bug. (Good news!)

I see a problem here. If we want to construct a valid context that can be
returned to the gdb stub, we need some memory. I see only two solutions for
this:

a/ Have a structure in the thread class that can contain this context.
b/ Allocate this structure on the stack just before switching thread - in
addition to the space already used to store the switch context 
c/ Have the same structure for the switch context and the full context, and
so construct the full context at every thread switch.

Providing that I've get it all right since the beginning, here are my though
about implemting such solutions

a/	Up: Is seems easy to implement.
	Downs: require a change for all archs and take extra memory.
b/	Up: Only needs to change i386 code
	Down: Less easy to implement, take extra memory on threads stacks
(but easy to  get rid of this Down when not in debug mode)
c/	Up: Maybe the more logical (same context for interrupt or thread
switch)
	Down: Probably less efficient for thread switching (and not easy to
change this when not in debug mode)


> 4/ The HAL_GET_GDB_REGISTERS macro (in fact the corresponding 
> function) is buggy : it should transmit to gdb the saved 
> context passed as the second argument. A priori another i386 
> pc specific bug (Good news!)

Another soultion could be not to return any context when saved_context is
null and to treat this specific case in the dbg_getthreadreg function. Such
a change would apply to all arch however.

One concern anyway is to know if the problem I experience only occur with
the i386 PC platform. 

For what I see, I think the same problem may occur in any arch where the
thread and interrupt contexts are different.

Thanks

A+

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com