OSDev.org

I've never used objdump before, but I hope is done correct
And out.txt can be found here: http://penguinpower.frac.dk/out.txt

Zioo wrote: I've never used objdump before, but I hope is done correct

Code: Select all

objdump -b binary -m i386 -h -D -t cls.bin > out.txt

And out.txt can be found here: http://penguinpower.frac.dk/out.txt

Ugh. disassembly of .data section. Luckily it ended up right in alignment:
That reads hello world.

It also explains the error. You aren't using any data if this hello world-bit isn't in it. So, the first byte is an instruction, and you can run it. If you put in "Hello World!" at the start of the file, it can't run that and it will crash. It'll probably crash on location 1/2, using a GS segment prefix with an instruction that can't use it.

Conclusion of this story:

- Don't start binary files with data
- Use a proper executable format for less surprises


----

Can't understand why it puts it at the very top of the file though, so I'm not sure how to fix it. Could you assemble it to an ELF relocatable file (gcc -c -o sth.o sth.c) and objdump that?

All right..

Heres the objdump output from the .o file http://penguinpower.frac.dk/out1.txt

As Candy said: Your binary file begins with the string "Hello world", which got linked into the .text section somehow. If your bootloader jumps to offset 0 of that binary, you're executing [tt]dec %eax[/tt] as first instruction...

Solar wrote: As Candy said: Your binary file begins with the string "Hello world", which got linked into the .text section somehow. If your bootloader jumps to offset 0 of that binary, you're executing [tt]dec %eax[/tt] as first instruction...

There's something wrong at a level before the linker, since the .text output in the code file also contains main at 0x10, with "Hello World!" at 0x0.

Quick solution: put .rodata in with .data
Decent solution: Use an object file format that allows main to be anywhere
Arrogant solution: Stop using COFF as intermediate format and go to a decent format such as PE or ELF. This requires changing compiler or compiling your own (try the OSFAQ, cross-compiler guide).

Your pick.



@Solar:
"Somehow" just doesn't explain it for me. I have to get to the bottom of it and know the cause

I agree with you in general, but very few "bug reports" on a forum like this include enough information to find the real reason without lengthy Q&A. (Tools used, configuration / target format of those tools, command line options, linker scripts...)

Hmm, yes I can see that the file start with Hello World...
I tried to move *(.rodata*) to the data section but without any difference..
Maybe I just should try to implement ELF binaries instead

Zioo wrote: Hmm, yes I can see that the file start with Hello World...
I tried to move *(.rodata*) to the data section but without any difference..
Maybe I just should try to implement ELF binaries instead

Well... that would explain, since the second objdump showed that it's happened before your data was dumped in with the code.

Did I say it was going to work? hm... not good.

You could try -fwritable-strings to put it in there (that's a compiler option at least, so it would work better). Other than that, make a crosscompiler.

You don't have to implement ELF or PE binaries, just use them as intermediate format. Same as you use C to transfer your thoughts and logic to assembly, if you'd used QBasic it wouldn't have worked due to limitations. So, switch to a different intermediate, and try again.

IIRC, COFF can't do anything but text/data/bss. GCC puts rodata in with text then, since they're commonly put together. In your case, that ends up being a very fatal mistake.

Lame solution I thought of as well: declare a pointer at the top and put the pointer content at the top of the file. If GCC is still as much like it as I knew it, it could work.

Oh, I see.. That could i also try...

I've also found another solution. If I use the same little assembly load file, I use to jmp to the kernels main function, does it also works fine..