ld bug on 2.6.11 ?

[nobody]

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 ?

[Frank Kotler]

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

[nobody]

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.

[nobody]

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