[ECOS] Re: hal/i386/pc...

[Jesper Skov <jskov at cygnus dot co dot uk>]

>>>>> "Patrick" == Patrick O'Grady <patrick@plasticgrape.com> writes:

Patrick> I've been running with CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT
Patrick> turned off; after I understand more about eCos' thread
Patrick> contexts I'll play with this a bit--so the current stub is
Patrick> incomplete.  I'm also having a problem updating the values of

That's what I meant by "comes for free with hal common". There should
be no need for thread related handling in the architecture/platform
stub code.

Patrick> the CPU registers: if I stop a program, and 'print $eip', it
Patrick> prints the right value; but when I 'print $eip=0x55aa',
Patrick> followed by a 'c', it resumes from the breakpoint instead of
Patrick> my new address...  so I've got some kind of register
Patrick> assignment problem.  It's kinda odd that I can read the
Patrick> current values, but not modify them in a way that sticks.
Patrick> I'm sure that it's something simple...  so far it's been
Patrick> easier to just reboot the target PC after finding bugs than
Patrick> to debug the stub itself!

Hard to say what the problem is - but personally, I'd put that high on
the list of things to get fixed. Nothing beats a good debugging
environment when you have to nail those last bugs.

Patrick> The next thing I want to look over is the HAL code supporting
Patrick> context switching: The linux synthetic
Patrick> HAL_THREAD_SWITCH_CONTEXT macro works great in the target PC
Patrick> when called as a function; but I'm not exactly sure how an
Patrick> ISR (specifically the clock ISR) can create a preemptive
Patrick> context switch.  Since the macro itself doesn't save all the
Patrick> registers (eax, ecx, edx), there seems to be some other call
Patrick> which will save these registers (and maybe more) too.  It's
Patrick> quite likely that context switching code may be responsible
Patrick> for the register amnesia noted above.  I also want to learn
Patrick> more about how DSRs are called.

Indeed, the other architectures rely on the interrupt handler to save
part of the register set - the context save/restore functions really
only have to save the callee-save registers; all other registers
should be saved prior to function entry (by virtue of the ABI).

Patrick> I've got a question about ISR stacks--what stack should ISRs
Patrick> switch to?  And where is the proper place to define
Patrick> this--does the kernel reserve a stack, or should I have the
Patrick> HAL do it transparently?  Is there a standard macro for
Patrick> configuring it's length?  And finally, do you include any
Patrick> utility functions for detecting the actual amount of stack
Patrick> used--this is usually a very simple routine which fills the
Patrick> stack buffer with some value (VxWorks uses 0xEE), and later
Patrick> on searches through the buffer for the lowest point where it
Patrick> was modified...  any clues here would be helpful.

If you look in some of the other architectures' arch/../vectors.S
files, you'll see that the HAL defines an interrupt stack - there's
also a configuration variable for defining its size.

There's a simple implementation of a stack monitor in
kernel/.../include/tests, but I don't think it fills the stack
initially.

Jesper