OSDev.org

I've recently moved to a phenom pc running 64bit #! linux.
I copied some 32bit (.com) examples over.

Using 32bit binutils and the command line "as test.s; objcopy -O binary a.out a.com; hte a.com"
I was able to transform the code... into the binary "00000000 04 00 00 00"
which is what I expected to see

This didn't work using 64bit binutils and I was told
a) its 'cos the relocs work differently in 64bit binutils &
b) that I'd need to use ld

My attempts over the last few days, using 64bit bin utils, have failed to reproduce the binary
and I wonder if someone show me how it's done with a little explanation.

This is as far as I got
gives "00000000 7c 00 40 00"

built with
as -o test.o test.s
ld -s -o test test.o
objcopy -O binary test a.com

gives "00000000 7c 00 40 00"
Assembling with nasm instead of as & then using ld gives a similar result but I think was 80 instead of 7c.
Perhaps this is correct and I just don't know what I'm looking at.

BTW nasm & fasm without any "help" from binutils reproduces the binaries on the 64bit OS just like they used to on my old PIII.

Any help appreciated.
Dean

It looks like you need a cross compiler (or more specifically, a cross linker). Clearly, you need a 32 bit toolchain to make 32 bit binaries.

Thx Nick
One of the .com files was a tiny standalone forth os ie 32 bit code with a 16 bit bootloader.

However, I'm not sure that
.int blob
blob:
is 32 bit specific and if it isn't ...
I'm not sure why 64 bit tools can't produce a .com file for this.

I have a nasm file and assembled it as elf64 on the phenom (I used to assemble it as just elf on my PIII).
64bit ld linked it fine and the executable runs fine.
If I can do this with what was previously built as a 32 bit elf file why can't I use 64 bit as & ld to build a .com file?
I suppose this is really my question.

Have you tried reading the manual? I've built my 32-bit OS using standard installed gcc on debian(x64). You have to specify that you want the assembler to output an i386-elf and the same to the linker. If you invoke them via gcc you just have to supply the -m32 option.

I have read the manual and still can't do it.
I would be extremely grateful if you could illustrate the 3 lines i.e.
as....
ld....
gcc....

to turn this...
.int blob
blob:
into the flat binary...
"00000000 04 00 00 00"

This should be trivial compared to your OS and would help me a lot.

You can't - The expected output doesn't match your assembly, you want a dword zero, followed by a dword 4. The source only specifies one number, and it's definately not 0x0000000400000000.

since you're using nasm, why not just output a flat binary directly?

Thx Combustor
You're very quick off the mark
I wrote the post and guessed the hex output pattern initially.
I needed to post it so I could go back and get the right numbers, higher up in the thread and then edit them back into the lower post.

Your comments may refer to my guess and not the proper output, which is there now.

this is the output from hte
"00000000 04 00 00 00"
i.e.
address | file contents
00000000 | 04 00 00 00

If your comments are still valid then I don't understand them and would be grateful if you could explain.

Re Nasm
This is an entirely different problem to the other one we were talking about i.e. this is about a complete OS written entirely in gas that I'm trying to rebuild using gnu's 64bit toolchain.
As such nasm has no place here (I wish it did!).
The os builds with gnu's 32bit tool chain fine on the 64bit pc but I'd really like to get to grips with the 64bit toolchain.

That's why I'd like to see how you produce the above output (effectively a .com file) from the above input using the gnu 64bit tool chain.

I hope this clarifies things and sorry if I confused you.

You'll probably have to use --32 for as and -melf_i386 for ld.

Thx for
>>You'll probably have to use --32 for as and -melf_i386 for ld.
I'll will give it a try.

Using the 32bit tool chain to build the os I only had to type...
as color.s #produces a.out
objcopy -O binary a.out a.com

There are no sections or _start s in the code at all
which suggests that I'll have to insert some to use with ld.

Additionally I note that "ld -V" results in...
GNU ld (GNU Binutils for Ubuntu) 2.19.1
Supported emulations:
elf_x86_64
elf_i386
i386linux

I was wondering what "i386linux" was for. I haven't found anything on it.

bobl wrote:Re Nasm
This is an entirely different problem to the other one we were talking about i.e. this is about a complete OS written entirely in gas that I'm trying to rebuild using gnu's 64bit toolchain.
As such nasm has no place here (I wish it did!).

Then you might want to try Yasm - it can do whatever NASM can, plus it supports gas' ATyuckT syntax.

Yasm is a very good suggestion indeed.
I tried it a week or two ago & found that it couldn't handle the OS' macros.
When I read deeper the Yasm people said they're working on it.
I also found Yasm's error messages more helpful than nasm's.

.text
_start: .global _start #keeps ld happy
.int blob
blob:

as --32 -o test.o test.s
ld -melf_i386 test.o
objcopy -O binary a.out a.com
hte a.com
produces
00000000 | 58 80 04 08

which doesn't reproduce the same as the 32 bit tool chain
WOW!

bobl wrote:00000000 | 58 80 04 08

58 80 04 08 => 08048058 looks like the address of blob or _start to me

I'm sure what you say is true but this seems a problem to me.
ie the bootloader runs from 0x7c00 and once everything's loaded it all gets relocated to addr 0x0 and runs from there to maximise memory usage ie it's a standalone forth image.

With addresses like 08048058 instead of 00000004 isn't this is going to mess everything up?

EDIT:
Adding "-Ttext=0" to the ld command line eliminates this discrepancy between the two tool chains.

Phew!