Well in my x86 emulator I'm wanting to make it the "os devers friend" as far as for debugging but also be fast..
so what would be most useful for debugging or testing your OS?
right now I have
1. support hooking in gdb somehow
2. dumping simple cpu info..(of course)
3. support breakpoints
add on to it...
What would you like in an OS debugger?
fully programmable tracing... and a "back up" feature.
As in, you hit a cli/hlt and then use the debugger to back up 20 instructions... but that would be somewhat difficult.
Oh, and an external hex editor to look at arbitrary memory... even hooking into biew would be nice, (it works on Unix and Windows, so everybody with a modern OS should be able to use it.)
As in, you hit a cli/hlt and then use the debugger to back up 20 instructions... but that would be somewhat difficult.
Oh, and an external hex editor to look at arbitrary memory... even hooking into biew would be nice, (it works on Unix and Windows, so everybody with a modern OS should be able to use it.)
My project: Xenon
like what do you mean?programmable tracing..
how would that be useful? and also backing up 20 bytes is easy but instructions is a bit harder..As in, you hit a cli/hlt and then use the debugger to back up 20 instructions... but that would be somewhat difficult.
hmm dunno how I'll do it but that would be very niceOh, and an external hex editor to look at arbitrary memory... even hooking into biew would be nice, (it works on Unix and Windows, so everybody with a modern OS should be able to use it.)
another thing I thought of is maybe being able to read symbol files and then do variable watching...
I don't care much for speed, but I'd love to be able to watch what is going on in memory while it's running and pause, single step, break points, etc. I don't think a symbol thing would be worth the effort, unless by symbol you mean just type in a name and memory location 
. That would be about all you would need, if you don't know where a symbol got loaded into your OS you have issues, unless of course it's that far along that you are loading many apps into allocated locatinos, in which case you should have already have a method of displaying info to the screen to figure out variable locations or otherwise.
. That would be about all you would need, if you don't know where a symbol got loaded into your OS you have issues, unless of course it's that far along that you are loading many apps into allocated locatinos, in which case you should have already have a method of displaying info to the screen to figure out variable locations or otherwise.
Yeah, any modificatins should have a nice simple config script or clickable gui, also a plugin system of sorts that can grab/modify information would be great too! So if I didn't likeyour debugger, I could write a plugin debugger or memory viewer that can do exactly what I needed. A small config to turn on/off features would be great, the bochs config file is wonderful but annoying to modify, a point/click editor for it would be nice (although, i guess that wouldn't be to hard to make for bochs either, i'm just lazy,lol).
I think that one of bochs' features is plugins...
The next step would be designing the emulator from scratch to be enterily modularized and include text files to define machine "personallities"... Something which I think Bochs' developers never thought about...
For example, one could ask the emulator to perform like an old IBM PC, so the emulator would read-in the corresponding information file to decide what plugins to load...
For example, if you look at the FreeDOS homepage you will smile when you read that the core apps must run on an 8068 (I read something like that, but I don't remember where)! Where will they find nowadays an 8086 to try and see if the app runs as expected??!
Hopefully, this is an extreme case... But what about a developer that wants to know if his OS runs on a relatively old computer but doesn't know anyone that still has such a computer?
I have an old 486SX in my house to test my code, but if I didn't have one I would have much more work in investigating whether the code runs on older machines or not...
JJ
The next step would be designing the emulator from scratch to be enterily modularized and include text files to define machine "personallities"... Something which I think Bochs' developers never thought about...
For example, one could ask the emulator to perform like an old IBM PC, so the emulator would read-in the corresponding information file to decide what plugins to load...
For example, if you look at the FreeDOS homepage you will smile when you read that the core apps must run on an 8068 (I read something like that, but I don't remember where)! Where will they find nowadays an 8086 to try and see if the app runs as expected??!
Hopefully, this is an extreme case... But what about a developer that wants to know if his OS runs on a relatively old computer but doesn't know anyone that still has such a computer?
I have an old 486SX in my house to test my code, but if I didn't have one I would have much more work in investigating whether the code runs on older machines or not...
JJ
That's a pretty good idea, taking it a step farther
I think I would do it more as config file templates, or like in the UI be able to specify "Setup as an IBM PC" or whatever
hmmm... gave me an idea for a better true, emulation
tell the devices to use my own timing functions; like have my own little timer type thing(PIT) and then to have a "slow" pc we will not only keep the instruction-per-seconds at a slower rate, but also have the timer to keep in sync with this slower rate rather than the fast rate of the host pc..kinda hard to understand, I know but I tried...(note this will defianetly be optional)
also in my config files I will have things to keep it portable.. like
win32_only: and the rest of the line is only executed if were on win32
and I will have "device sets" which are basically predefined(in a text file somewhere) of devices to load and arguments to send them..(basically like #include in a config file except it's only intended for devices)
I think I would do it more as config file templates, or like in the UI be able to specify "Setup as an IBM PC" or whatever
hmmm... gave me an idea for a better true, emulation
tell the devices to use my own timing functions; like have my own little timer type thing(PIT) and then to have a "slow" pc we will not only keep the instruction-per-seconds at a slower rate, but also have the timer to keep in sync with this slower rate rather than the fast rate of the host pc..kinda hard to understand, I know but I tried...(note this will defianetly be optional)
also in my config files I will have things to keep it portable.. like
win32_only: and the rest of the line is only executed if were on win32
and I will have "device sets" which are basically predefined(in a text file somewhere) of devices to load and arguments to send them..(basically like #include in a config file except it's only intended for devices)
Something like this, yes...hckr83 wrote:That's a pretty good idea, taking it a step farther
I think I would do it more as config file templates, or like in the UI be able to specify "Setup as an IBM PC" or whatever
Another solution would be an include directive that would ask the emulator core to process some device-declaring headers that would say that the devices exist (the devices that are usually present in a Compaq Armada laptop, for example) and give a default configuration to them...
Then, and below the include directive, the user (or a specialized configurator) could modify and/or include more devices...
When I was writting my post, I thought about suggesting this... But I think you will have more challenges in making your emulator fast, than in making it slow!hmmm... gave me an idea for a better true, emulation
tell the devices to use my own timing functions; like have my own little timer type thing(PIT) and then to have a "slow" pc we will not only keep the instruction-per-seconds at a slower rate, but also have the timer to keep in sync with this slower rate rather than the fast rate of the host pc..kinda hard to understand, I know but I tried...(note this will defianetly be optional)
Unless you plan using some state-of-the-art emulation technique, like dynamic translation or virtualization (while still using the host CPU to execute non-privileged instructions)...
You can extend it in an #ifdef -like way...also in my config files I will have things to keep it portable.. like
win32_only: and the rest of the line is only executed if were on win32
JJ
PS: I took a glance at Open86 from SVN rev. 10 and I think you should give yourself the time to format and comment the code a bit more... Also, the makefile looks pretty strange... It is more like a shell script than a makefile (and you would avoid much overhead if it was a shell script!)...
PS2: I once thought about an emulator that interpreted the pseudo-code that appears in the Intel manuals! That would simplify updates a lot if ever becomes nearly perfect!...