This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

hal/i386/pc...




On 8 Oct 1999, Jesper Skov wrote:

> >>>>> "Patrick" == Patrick O'Grady <patrick@plasticgrape.com> writes:
> 
> [snip]
> Patrick> - The GDB stub is about 75% in place.  It doesn't know
> Patrick> anything about threads yet, and some of the exceptions aren't
> Patrick> supported properly.  However, the breakpoint exception, is
> Patrick> working great.
> 
> Patrick> - I've just yesterday been able to get the clock ISR to work,
> Patrick> so the threading support is next on the list.
> [snip]
> Patrick> I'm hoping to have the threading stuff figured out by the end
> Patrick> of next week--I'll post it as soon as I feel like it's
> Patrick> usable!  Stay tuned...
> 
> 
> Is it kernel thread support or GDB thread debugging support you want
> to implement? The latter should come pretty much free with the
> hal/common stub code.
> 
> Jesper
> 

I've been running with CYGDBG_KERNEL_DEBUG_GDB_THREAD_SUPPORT turned off;
after I understand more about eCos' thread contexts I'll play with this a
bit--so the current stub is incomplete.  I'm also having a problem updating
the values of the CPU registers:  if I stop a program, and 'print $eip', it
prints the right value; but when I 'print $eip=0x55aa', followed by a 'c',
it resumes from the breakpoint instead of my new address...  so I've got some
kind of register assignment problem.  It's kinda odd that I can read the
current values, but not modify them in a way that sticks.  I'm sure that
it's something simple...  so far it's been easier to just reboot the target
PC after finding bugs than to debug the stub itself!

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

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

Cheers...
-patrick




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]