David Given writes:
>
> [...]
> >I gave this another try yesterday with the new release, and it works
> >really well. The only real problem with it is that it does not detect kep
> >presses very well. Most keypresses are either missed, or come up multiple
> >times. Any idea how to get round this?
>
> The last time I tried it (and I admit I hardly gave it a thorough testing) it
> seemed to detect keypresses all right. Has the keyboard code changed in any
> way? The emulator provides both hardware emulation and a BIOS routine; I'd
> expect the BIOS entry point to provide rather better support.
>
> >The debugging feature is great. I haven't really tried to use it very much,
> >but just being able to interrupt it and find out where the PC is at any
> >time is really useful.
>
> It occurs to me that it would be possible to extend the debugger so that it
> knew about ELKS kernel variables very easily (after all, ps does it). This
> would let you browse kernel structures, or possibly modify them. Would this be
> useful?
>
I have been thinking along the same lines. I have just been playing with
the debugger and it could do with some tweaks.
My first request would be that simply pressing return in the debugger
repeats the last command. This makes it much easier to step through code.
Secondly, a sorted version of the kernel system map and some ELKS specific
code could be used to give useful about where the code is currently,
what the stack backtrace is, and what data the current instruction is
accessing, as well as the ability to browse and modify the data segment.
Are you interested in coding any of this stuff? I would enjoy doing it
myself, but I am trying to discipline myself to sticking to writing
kernel code at the moment.
Al
