NASM - The Netwide Assembler
NASM Forum => Using NASM => Topic started by: nobody on June 14, 2005, 09:06:13 PM
-
hello guys !!!
i'll show an example code:
----------------- new.asm -------------------------
bits 32
section .text
global _start
msg db "och bin",0x0
msg_len equ $-msg
_start:
pusha
mov eax,4
mov ebx,1
mov ecx,msg
mov edx,msg_len
int 0x80
popa
xor eax,eax
inc eax
int 0x80
---------------------------------------------------
So I compiled that code under linux (kernel version 2.6.5):
bash# nasm -f elf -o new.o new.asm
bash# ld -o new new.o
The binary worked perfectly. Then I tried to compile the same
source on my actual kernel (kernel version 2.6.11) with the same commands:
bash# nasm -f elf -o new.o new.asm
bash# ld -o new new.o
bash# ./new
Segmentation fault.
Hm...Thats strange. Before compiling the same source on my actual kernel ,I even tried to execute the binary I've compiled under 2.6.5 and it didnt work : Segmentation fault.
I already wrote to people from kernel.org and they said me I'm kinda crazy. "Thats no kernel bug.We're sure about it."
Well..What the heck happened ?
-
Very strange!!! Your code looks fine and, as expected, works fine on my 2.4.26. Couple of things you could try... "strace new" and see if you can determine where the segfault occurs - before the message appears, I take it... Try moving your data after the code - maybe your new kernel's trying to execute it (highly unlikely, I would think). Try putting your data in a .data (or .rdata) section - maybe the new kernel is fussy about reading a code segment, as well as writing it. That's about all I can think of...
*Please* let us know if you find anything - I can see this being reported as a "nasm bug"... which it might be, but I don't think so. Never trust anybody who says they're "sure" there are no bugs in their code! That's what NASA said just before they plowed into the surface of mars :)
Best,
Frank
-
HI !! thank your for your quick answer.
So strace will show this output on the old binary I've compiled :
bash# strace ./new
execve("./new", ["./new"], [/* 78 vars */]) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
The new code:
---------------------- new.asm ----------------
bits 32
section .text
global _start
_start:
pusha
mov eax,4
mov ebx,1
mov ecx,msg
mov edx,msg_len
int 0x80
popa
xor eax,eax
inc eax
int 0x80
section .data
msg db "test",0x0
msg_len equ $-msg
bash# nasm -f elf -o new.o new.asm
bash# ld -o new new.o
bash# ./new
testbash#
So as u can see it worked very fine.
I tried something else :
---------------------- new.asm --------------
bits 32
section .text
global _start
_start:
pusha
mov eax,4
mov ebx,1
mov ecx,msg
mov edx,msg_len
int 0x80
popa
xor eax,eax
inc eax
int 0x80
msg: db "test",0x0
msg_len equ $-msg
But it didnt work aswell.So the problem is that the kernel needs a .data section for the data. Hmm ...But thats quite annoying. I've been used to use no .data in my programms.
-
Okay, that's a good start toward tracking down what's happening here.
I did a quick "experiment"... Installed "blueflops" - a distro that fits on two floppies - but *does* have that 2.6.11 (.??) kernel. Haven't got Nasm running on it (yet), but a Fasm example (a simple "hello world") also segfaults on that kernel. (*does* have a "data" section, as Fasm does 'em, but before the code...)
I'm not sure whether this should be considered a "bug" in the new kernel, or merely a "new requirement". Doesn't seem like much of a "feature" to me, either, but it may be intentional.
This needs more looking into. Right now I'm up to my neck in trouble getting Linux to run at all (long story) - I'm posting this from Windows (ugh) it's so bad... But I'll get back to it. Thanks for the input!
Best,
Frank