Author Topic: coff file format question  (Read 29887 times)

Keith Schincke

  • Guest
coff file format question
« on: January 31, 2005, 07:36:16 PM »
(This could almost piggyback off of the how to write char to output question)

I am working in DOS enviroment with nasm to compile my asm files and the djgpp linker to link. I am compiling my testio.asm file into a coff format and am trying to print a string from memory to the output. nasm throws the following error when it tries to compile the code: "COFF format does not support non-32-bit relocations"

Here is my asm code:
.DATA
line db 'This is the end', '$'
...
...
...
mov dx, line ; error happens here.
mov ah, 09h
int 21h

Thanks for any and all help. I am obviously new to [n]asm and DOS programming.

Keiths

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: coff file format question
« Reply #1 on: February 01, 2005, 02:56:06 AM »
COFF is a 32-bit format, so you want "mov edx, line" - strange as that seems to use with "int 21h". It's not really "dos code", but "dos extender code". If you don't intend to be writing 32-bit code, you don't want "-f coff"... maybe "-f obj", but you'll need a different linker (Alink - right here at SourceForge - works well with Nasm)... or you could use "-f bin" to produce .com files directly - I think that's the easiest place to start.

Incidentally, ".DATA" is just a label to Nasm - you want "section .data" - don't forget to switch back to "section .text" before the code starts.

Best,
Frank

Keith Schincke

  • Guest
Re: coff file format question
« Reply #2 on: February 01, 2005, 04:20:59 AM »
I had a comple of macros to shorten some typing. Here is the full code of the standard program #1:

org 100h
segment .data
   L1   db   'Hello World!',10,13, '$'

segment .text
    ; print hello message
    mov edx,L1
    mov ah,9
    int 21h

the_end:
    ; call program end
    mov ah,4Ch
    int 21h

I can compile this with "nasm -o hello3.com hello3.asm" and produce a COM file as expected.  I am wanting to extract things into several source files in the future. Commenting out the first line and compiling with "nasm -f coff -o hello3.o hello.asm" "ld -o hello3.com hello.o" produces a COM file that prints no correct output.

Does the ld from djgpp link COFF files well or am I doing something wrong?


Keith

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: coff file format question
« Reply #3 on: February 01, 2005, 03:31:24 PM »
Hi Keith,

I haven't actually tried "-f coff" much, so I'm kinda guessing here... I have, over on the "dos side", a "hwcoff.asm" which is virtually identical to what you've got (as you've noted, "org" is recognized by "-f bin" only). I *thought* it worked okay - not in the mood to reboot to dos to test it at the moment... I can think of a possible reason why neither your example nor mine would work...

You give "ld the "-o hello3.com" switch. This only controls the *name* of the output file, but unless I'm mistaken, what you'll get is actually an "MZ" executable. This in itself isn't going to hurt. Dos sees *either* .com or .exe as a file extension, and it examines the first two bytes for the "MZ" signature, and loads the file according to *that*, not the file extension. ("command.com" hasn't been a .com file since about dos 2.0 or so!) The difference is, a .com file starts up with segment registers (ds and es, at least) pointed at your one-and-only segment. An .exe loads with ds and es pointed to the PSP - you need to start a normal dos .exe with:

mov ax, data
mov ds, ax
mov es, ax ; if you're using es
...

I *recall* that my example without that worked, but I'd try adding that to see if it'll get you some output... The reason this might *not* be necessary is that djgpp's ld adds a considerable "runtime" to your executable - you've probably noticed the difference in size! This *might* take care of that for you...

I'll try to remember to do some testing with "-f coff" the next time I reboot. Right now, that's the only thing I can think of that might be causing a problem...

Best,
Frank