Author Topic: bin files & linux  (Read 16205 times)

nobody

  • Guest
bin files & linux
« on: January 22, 2005, 03:29:04 PM »
Hi!i know almost nothing about linux,and i have a problem running an assembly code..At first,i wrote this code for Dos and i used -f bin for output(compiling and running in Dos had no problem).but when i try to compile and execute this file in Linux i get a message "cannot execute binary file".I tried to compile it as elf but there are problems.Can somebody help me on how to start from an .asm file to result in an executable to linux file?Thanks a lot!!!

(P.S. i 've already used chmod command.)

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: bin files & linux
« Reply #1 on: January 23, 2005, 05:58:55 AM »
If you create Linux executables the "regular way", you shouldn't have to use chmod - ld should create the file with the correct permissions.

nasm -f elf myfile.asm
ld -o myfile myfile.o

Add the "-g" switch to Nasm if you want "debug info" in the executable - helps gdb or ald to be a little "friendlier". If you *don't* want debug info, adding the "-s" switch to ld will produce a smaller file. You probably don't want to worry about "small" at this point - get it working first!

It's possible to use Nasm's "-f bin" output format to create an ELF executable directly, without use of a linker. You'll need to build the "elf header" by hand. Macros are available to assist with this - grab the "asmutils" package from http://www.linuxassembly.org (other useful info available there, too!) In this case, you *will* need to use "chmod a+x" to make the file executable. Possible to do this for dos MZ and Windows PE files too, but it isn't a very "flexible" method. I'd suggest using a linker.

Source code intended for dos (or Windows) is unlikely to work under Linux, even if you get it to assemble and link - different interrupts! I'll post a simple-minded "hello world" to get you started. More examples at linuxassembly.org, in the "test" directory if you have the Nasm source, and at http://groups.yahoo.com/group/linux-nasm-users in the "files" section...

Ignore the irate squawking from the Penguin :)

Best,
Frank

;---------------------

global _start ; inform linker

section .text

_start ; default entrypoint known to ld

nop        ; parking space for gdb - not required
           ; but gdb likes to see a one-byte
           ; instruction first
mov eax,4   ; sys_write
mov ebx,1   ; STDOUT
mov ecx,msg ; buffer
mov edx,msg_len  ; number of bytes to write
int 80h

mov eax,1  ; sys_exit
int 80h

section .data
msg db 'Hello, world',0Ah
msg_len equ $ - msg

;-------------------------------

nobody

  • Guest
Re: bin files & linux
« Reply #2 on: January 23, 2005, 06:26:54 PM »
Thanks frank(especially for the simple example).Using this structure,
i created an elf output but when i try ld, i have problems with the 16/32 mode (actually,i think that this is the problem). I am moving between 16 and 32 bit mode (real - protected etc). i am using [BITS xx] to change mode,but ld shows this error

"relocation truncated to fit ...   .data".I tried both [BITS 16] and [BITS 32] to the data section but i see no difference.

Once again,the same code worked under Dos (now i've changed the interrupts before as you mentioned before)

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: bin files & linux
« Reply #3 on: January 24, 2005, 03:05:00 AM »
Okay... dos is inherently 16-bit code - you can switch to pmode and 32-bit code if you want to (won't work in a "dos box", but in "real dos" it's okay). Linux is inherently 32-bit code - 16-bit code simply isn't going to work. This may not be true if you're "hacking the kernel", but from "userland" code - forget it!

As I understand it, the ELF spec is 32-bit only, but there are "gnu extensions" that allow 16-bit (and 8-bit?) relocations. I have no idea how - or why - you'd use 'em.

Maybe if you explain exactly what you're trying to do - maybe post the code - someone can provide more help... or not...

Best,
Frank