Message board for the users of flat assembler.
> OS Construction > How to debug INT calls in BOCHS?
nkeck72 10 Oct 2016, 18:37
In NOS, I have set up an API on INT 21 for use by the programmer/user to perform basic tasks without long and complicated code. However, as of the moment, I am having issues getting this API called from the kernel. I have done several step-throughs with Bochs, to no avail. I cannot seem to figure out what is wrong with my code. As far as I can figure out, the API's resident address in RAM (0x8000:0x0000) is getting into the IVT correctly, and the API is getting put in the correct spot, but when I perform an INT 0x21, Bochs seems to "get lost", i.e. it doesn't execute the API code, but whatever it does execute has a LOCK prefix that isn't supposed to be there and it locks up the "processor". It does this every time, I have tried swapping the values in the IVT, I've done memory dumps and the API is always at 0x8000:0x0000 like it's supposed to be. I have an issue on GitHub if you want more info: https://github.com/nkeck720/nos/issues/38
I haven't tested this on real hardware, but VirtualBox and DosBox both seem to do the same thing.
It always fails at the "test call", where I check to make sure that the API is installed correctly:
; We need to be sure that INT 21 works. Function 00 is an install ; check, and so we will call it with that value. mov ah, 00h int 21h ; If AX=5555h, we are done here. cmp ax, 5555h jne api_load_error
As far as I can tell, it never makes it to the CMP instruction, and I can't tell where on earth Bochs went off to because its builtin debugger doesn't trace interrupt calls. all I get is this:
I'm at a loss here. Can someone help me out with this?
EDIT: Yes, I have made sure ES=0x0000, so in effect my code is pointing at 0x0000:0x0086 and 0x0000:0x0084 in the IVT.
It may look hard, but it won't take long if you take it one byte at a time.
|10 Oct 2016, 18:37
Feryno 11 Oct 2016, 09:50
Hi nkeck72, I debugged my projects using bochsdbg a lot, but the last time it was half a year ago.
When you are on int 0x21 instruction at address 1000:0150, instead of step over command n - try whether step into command s is not able to enter the interrupt handler (I do not know from my head). If unable, then this way should work:
put breakpoint at physical address 0x80000, (from my head) it is command pb 0x80000
continue execution using command c
when you hit the breakpoint you can debug your int 21h handler to catch that ugly instruction with the lock prefix
|11 Oct 2016, 09:50
nkeck72 12 Oct 2016, 04:36
Thanks. Will try this tomorrow when I get the chance.
|12 Oct 2016, 04:36
< Last Thread | Next Thread >
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.