From: Jesper Skov <jskov@cygnus.co.uk>
To: "Patrick O'Grady" <patrick@plasticgrape.com>
Cc: ecos-discuss@sourceware.cygnus.com
Subject: [ECOS] Re: hal/i386/pc...
Date: Tue, 12 Oct 1999 01:29:00 -0000 [thread overview]
Message-ID: <14338.61502.616494.520520@thinktwice.zoftcorp.dk> (raw)
In-Reply-To: <Pine.BSF.4.05.9910111223380.58038-100000@pru.plasticgrape.com>
>>>>> "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
prev parent reply other threads:[~1999-10-12 1:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-07 9:29 [ECOS] probably a FAQ, but: how many x86 ports are in motion out there? Roland Schwarz
1999-10-07 9:53 ` [ECOS] probably a FAQ, but: how many x86 ports are in motionout there? Patrick O'Grady
1999-10-08 1:45 ` [ECOS] probably a FAQ, but: how many x86 ports are in motion out there? Jesper Skov
1999-10-11 13:03 ` [ECOS] hal/i386/pc Patrick O'Grady
1999-10-12 1:29 ` Jesper Skov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=14338.61502.616494.520520@thinktwice.zoftcorp.dk \
--to=jskov@cygnus.co.uk \
--cc=ecos-discuss@sourceware.cygnus.com \
--cc=patrick@plasticgrape.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).