سؤال

I'm using gnu as for a simple boot. It's something like this:

.text
.org 0x7c00
start:
    movw $0x7c0, %ax
    movw %ax, %ds
    movw %ax, %es
    leaw greeting_msg, %si
    call prtstr
....

end:
    .fill 510-(end - start), 1, 0
    .word 0xAA55

while the hexdump of output is:

○ → hexdump bare.o 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0007c00 c0b8 8e07 8ed8 8dc0 7f36 e87c 0046 02b8
0007c10 bb4f 4115 10cd f883 754f a133 4f01 3e8d
0007c20 7c97 15b9 cd41 8310 4ff8 2275 8b66 9b16

which doesn't behave the same as ORG in nasm? If I use NASM, it outputs something like:

 ○ → hexdump test_org
0000000 c031 d88e 14be ac7c c008 0674 0eb4 10cd
0000010 f5eb feeb 6557 636c 6d6f 2065 6f74 4d20
0000020 6361 6e69 6f74 6873 0a0d 0000 0000 0000
0000030 0000 0000 0000 0000 0000 0000 0000 0000

What's wrong here? Thanks.

هل كانت مفيدة؟

المحلول

There's nothing wrong, simply .org in GAS is not .org in NASM. .org in GAS indicates how much to advance the current location counter, and looks like this:

.org expr, fill

Where fill is what to use to fill, which defaults to zero if nothing specified (more info here)

.org in NASM indicates the memory address where this module will be placed (and thus generates correct branch and jump instructions) (more info here)

I suggest you use NASM for such flat binary files, worked always like a charm for me.

نصائح أخرى

You're comparing a binary (from Nasm) with a linkable .o file from (G)as. I think if you link your "bare.o" with ld... "ld -o bare.bin -oformat binary bare.o" (not sure of the syntax) you'll come up with something closer to what you expect. Or... just use nasm.

use ld -Ttext 0x7c00 --oformat=binary boot.o -o boot.bin.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top