[SOLVED] Partially written string literals

[kzinti]

It is very common for things to work on qemu and not on real hardware.

I would suggest trying bochs next. It does more validation / is less permissible then qemu.

[Stamerlan]

Hi, eisdt,

I don't see any mistakes now, but tomorrow on my work I'll have modified version of qemu and I'll show u which registers values are passed to int 0x10. I'm relocating now and I don't have any flash to try to boot from real hw.
May be it will help: if u already tried beep and calling printRegister twice, try to use colour 0x07 (instead 0x03), as far as I remember there was bug in colours on vm (I don't remember which one, but colours different from 0x07 where shown incorrectly) may be ur bios has same issue (it's very unlikely, but more research I can do only tomorrow)

P.S. on real hw do u see a separator ('_')?

Happy hacking!

[intx13]

It is very common for things to work on qemu and not on real hardware.

I would suggest trying bochs next. It does more validation / is less permissible then qemu.

I tested it in on Bochs, worked fine.

eisdt, what is the current status on your real hardware? Your code works on both Bochs and QEMU for me.

It does work on QEMU flawlessly indeed. It does not, though, work as well on real hardware for some hidden reason.

Can you be more specific? What are the current symptoms with the latest code? Still printing halfway and then hanging? Or not printing at all now?

[eisdt]

Can you be more specific? What are the current symptoms with the latest code? Still printing halfway and then hanging? Or not printing at all now?

The latest code and behavior thereof can be found here.

Accessing the variable is problematic, whether it's for printing the string pointed to by or the value of the address (printRegister).

I don't see any mistakes now, but tomorrow on my work I'll have modified version of qemu and I'll show u which registers values are passed to int 0x10. I'm relocating now and I don't have any flash to try to boot from real hw.
May be it will help: if u already tried beep and calling printRegister twice, try to use colour 0x07 (instead 0x03), as far as I remember there was bug in colours on vm (I don't remember which one, but colours different from 0x07 where shown incorrectly) may be ur bios has same issue (it's very unlikely, but more research I can do only tomorrow)

P.S. on real hw do u see a separator ('_')?

Happy hacking!

Colors are only meaningful in graphic mode, which I'm not currently using (code runs in text mode initially). The BIOS does seem to care about the page number, though. Yes, the separator is printed after 0xDEAD; thereafter, nothing. Not even the terminating '.' .

Likewise! I'd be very interested to know why variables seem to be alienated.

[Stamerlan]

Hi, eisdt,

qemu bios log:

Code: Select all

stub handle_10:1148:
   a=00000e35  b=0000030a  c=00000005  d=00000035 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0046
stub handle_10:1148:
   a=00000e37  b=0000030a  c=00000004  d=00000037 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0002
stub handle_10:1148:
   a=00000e30  b=0000030a  c=00000003  d=00000030 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0006
stub handle_10:1148:
   a=00000e30  b=0000030a  c=00000002  d=00000030 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0002
stub handle_10:1148:
   a=00000e35  b=0000030a  c=00000001  d=00000035 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0002
stub handle_10:1148:
   a=00000e5f  b=0000030a  c=00000000  d=00000035 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0046
stub handle_10:1148:
   a=00000e33  b=0000030a  c=00000005  d=00000033 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0046
stub handle_10:1148:
   a=00000e31  b=0000030a  c=00000004  d=00000031 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0002
stub handle_10:1148:
   a=00000e38  b=0000030a  c=00000003  d=00000038 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0006
stub handle_10:1148:
   a=00000e34  b=0000030a  c=00000002  d=00000034 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0002
stub handle_10:1148:
   a=00000e38  b=0000030a  c=00000001  d=00000038 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0002
stub handle_10:1148:
   a=00000e2e  b=0000030a  c=00000000  d=00000038 ds=0000 es=0000 ss=eef1
  si=00000000 di=00000000 bp=00000000 sp=000001f6 cs=0000 ip=7c30  f=0046

Did u fixed an issue with incorrect bx register value in printChar?

P.S. u may remove instruction on line 91 (test %cx, %cx), sub instruction sets ZF

Have a nice day!

[Combuster]

ss=eef1

Really?

[Techel]

Maybe compiler optimization? Disassemble the binary and compare.

[Stamerlan]

Hi,

2eisdt I run ur code on my hw (American Megatrends A06), only change I've done is mov $0x3, %bh -> mov $0x3, %bx in printChar function. All works fine for me. May be u have a problem when u r writing to flash, or if it's a hd check if u r writing to correct disk (which u r booting from) may be u boot from old version of ur bootloader?

2Combuster Why not? BIOS can use it's own stack (If u want I can find where it's done in SeaBios)

2Roflo I done it - everything fine.

Happy hacking!

[eisdt]

Maybe compiler optimization? Disassemble the binary and compare.

Assemblers don't perform optimizations as they can't see the logic of the code, unlike compilers for higher level languages (e.g. C); or you were perhaps referring to something else?

2eisdt I run ur code on my hw (American Megatrends A06), only change I've done is mov $0x3, %bh -> mov $0x3, %bx in printChar function. All works fine for me. May be u have a problem when u r writing to flash, or if it's a hd check if u r writing to correct disk (which u r booting from) may be u boot from old version of ur bootloader?

Thanks for trying the code on RHW. (lucky you!) You see 0xDEAD_$MSG_ADDRESS., right?
I don't use bootloaders -- it's just a USB 2.0 drive I write the code to. I then enter the BIOS, F8, boot it and hope to see what I programmed the CPU to do.

I thought the USB could be faulty, but I can successfully boot straight off from it on QEMU. ( -hda /dev/sdb ). I can not really figure out what's wrong. Right now I'm consider that the active page might change from boot to boot: therefore, I'll load the active one (INT 0x10, AH=0xF => AL) and write to it. I wanna also try again writing directly to the VGA display address, maybe something new is brought up.

[Stamerlan]

Did u disable secure boot and enable legacy boot mode?

P.S. U can manually setup video page http://www.ctyme.com/intr/rb-0091.htm to 0

[eisdt]

Did u disable secure boot and enable legacy boot mode?

If they were a problem the code wouldn't start at all, would it? Thing is that the code works at someone's will: I thought there was something wrong with the constants in general, so I placed a

Code: Select all

val:
      .dw 0xFFFF

and tried to print with printRegister and it worked fine. WTF! (pardon)

[intx13]

FYI the output I'm seeing in Bochs and QEMU is "57005_31848." It should be "DEAD_<whatever>." right?

Eh disregard forgot it's using decimal.

[eisdt]

FYI the output I'm seeing in Bochs and QEMU is "57005_31848." It should be "DEAD_<whatever>." right?

57005 is 0xDEAD and 31848 (0x7C68) is the address of the string. I get the same results on QEMU.

[intx13]

I tested on two laptops and was able to reproduce what you're seeing on one of them. The other one worked fine. This is interesting!

[Stamerlan]

Thanks for trying the code on RHW. (lucky you!) You see 0xDEAD_$MSG_ADDRESS., right?
I don't use bootloaders -- it's just a USB 2.0 drive I write the code to. I then enter the BIOS, F8, boot it and hope to see what I programmed the CPU to do.

Yep, I saw dead, separator, msg addr and point at the end. But I fixed misprint in printChar. Now I'll try to do it with misprint (I guess I shouldn't see anything)

P.S.

I tested on two laptops and was able to reproduce what you're seeing on one of them. The other one worked fine. This is interesting!

Maybe on some bios this function uses additional registers (such as cx, dx), which aren't documented?

P.P.S. I saw a message in any case... = \
Smth strange is happening