Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
(0) [0x00007c00] 0000:7c00 (unk. ctxt): jmp .+0x003c (0x00007c3e) ; eb3c
<bochs:5> s
Next at t=17845988
(0) [0x00007c05] 0000:7c05 (unk. ctxt): push di ; 57
<bochs:6>
Look at "jmp .+0x003c (0x00007c3e)" instruction that occurs but the EIP register becomes 0x00007c05 for the next instructions. I've tried the same version of bochs on Windows VIsta, it works fine and jumps to 0x00007c3e. Anyone has had the same problem? Or I'll think that something is wrong with the ubuntu as I've made some system changes prevously.
(0) [0x00007c00] 0000:7c00 (unk. ctxt): jmp .+0x003c (0x00007c3e) ; eb3c
<bochs:5> s
Next at t=17845988
(0) [0x00007c05] 0000:7c05 (unk. ctxt): push di ; 57
<bochs:6>
Look at "jmp .+0x003c (0x00007c3e)" instruction that occurs but the EIP register becomes 0x00007c05 for the next instructions. I've tried the same version of bochs on Windows VIsta, it works fine and jumps to 0x00007c3e. Anyone has had the same problem? Or I'll think that something is wrong with the ubuntu as I've made some system changes prevously.
There is one rare situation that probably could happen with Bochs (not sure if I had cleaned all these cases). If instruction bytes on the EIP were changed after Bochs had fetched them it might happen that Bochs will miss the updated and keep 'old' instructions in its trace cache. So indeed it executed some 4-byte instruction which is not jmp @ this EIP and therefore EIP advanced by 4 and not changed to 0x7c3e. Disasm is reading actual memory and always shows "right" code but emulated CPU cache might contain stale thing before it was modified by SMC.
If you know to reproduce the issue quickly (send me disk image + instruction to reproduce the story) I could check it and probably fix bug in Bochs. If not - never mind, chance that anybody else will run to same problem is negligible
I was never all that good with building programs from source, so where possible, I try to use Debs or even better a direct apt-get. You're using ubuntu: why not try:
Here I've upload as an archive, there is a bochsrc.txt and a hd1.img files. I've shortened the hard disk image to 10MB. Anyway don't care about what data is there on it. The scene is so that you run 'make' command in the extracted directory, or just the 'bochs' command using the bochsrc.txt file. I'll show it as a code as it will be easier to explain for me:
...
...
00000000000i[ ] reset of 'parallel' plugin device by virtual method
00000000000i[XGUI ] [x] Mouse off
00000000000i[ ] set SIGINT handler to bx_debug_ctrlc_handler
Next at t=0
(0) [0xfffffff0] f000:fff0 (unk. ctxt): jmp far f000:e05b ; ea5be000f0
<bochs:1> lb 0x7c00
<bochs:2> c
Well, we've loaded a break point at 0x7c00. The CPU will stop at MBR first and then at partition's bootsector. So:
...
...
00000836902i[BIOS ] bios_table_cur_addr: 0x000fbc74
00000849219i[BIOS ] ata0-0: PCHS=20/16/63 translation=none LCHS=20/16/63
00004729447i[BIOS ] IDE time out
00016726733i[BIOS ] Booting from 0000:7c00
(0) Breakpoint 1, 0x00007c00 in ?? ()
Next at t=16726794
(0) [0x00007c00] 0000:7c00 (unk. ctxt): jmp far 0000:7c05 ; ea057c0000
<bochs:3> c
(0) Breakpoint 1, 0x00007c00 in ?? ()
Next at t=16747479
(0) [0x00007c00] 0000:7c00 (unk. ctxt): jmp .+0x003c (0x00007c3e) ; eb3c
<bochs:4> s
Next at t=16747480
(0) [0x00007c05] 0000:7c05 (unk. ctxt): push di ; 57
<bochs:5>
Archil wrote:If you need further information about my Bochs installation or system setting, let me know and I'll do provide it.
Hope this all helps.
Bochs bugs are usually 100% reproducable on different platforms but I can't reproduce your issue on my Cygwin host.
Looks like in your case Bochs cache still holds 'jmp far 0000:7c05' instruction when you think you execute 'jmp .+0x003c' but I can't check it on my system ...
BTW, which gcc version on your ubuntu ?
Some first gcc 4.x.x build were known to generate such problems ...
