Re: [Nasm-users] Linux "hello world" segfault on 2.6.11

[Frank K. <fbk...@co...>]

Frank Kotler wrote:

> That appears to be "expected" behavior with 2.6.11+.

I'm not sure which version this started with, actually - lets say
"recent kernels".

>> I wonder
>> why I don't need to do this with the gnu asssembler.
> 
> Good question. Don't you? The code you cited:
> 
> http://www.tldp.org/HOWTO/Assembly-HOWTO/hello.html
> 
> ... indicates an explicit ".data" section for both the Nasm and (G)as 
> versions. If a (G)as version works without a ".data" section... perhaps 
> Gas makes a writable section at the end, whether you ask for one or not. 
> I haven't tried it. Only thing I can think of.

That seems to be the case. IOW, "return 42" *does* work okay when
assembled with Gas (the examples in Jonathan's book, e.g.).

.globl _start

.text
_start:
movl $1, %eax
movl $42, %ebx
int $0x80

Linked with ld, doesn't segfault. "objdump -h" says:

hwg.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0000000c  00000000  00000000  00000034  2**2
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .data         00000000  00000000  00000000  00000040  2**2
                   CONTENTS, ALLOC, LOAD, DATA
   2 .bss          00000000  00000000  00000000  00000040  2**2
                   ALLOC

OTOH, the "same code" in Nasm...

global _start

section .text

_start:
mov eax, 1
mov ebx, 42
int 80h

*Does* segfault! objdump says:

hw7.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0000000c  00000000  00000000  00000130  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .comment      0000001f  00000000  00000000  00000140  2**0
                   CONTENTS, READONLY

> The 2.6 code appears to 
> *require* that your executable have a writeable section, and that it be 
> at the end (ld apparently takes care of the latter, if we use it).
> 
> Curiously, marking the code section writeable seems to solve the problem 
> using Fasm, but *not* using Nasm. This *may* indicate a bug in what 
> Nasm's doing with "section .text write" - needs further research...

Or it could be ld's doing...

global _start

section .text write
  msg db 'hello world', 10
  msg_len equ $ - msg

_start:
     mov eax, 4
     mov ebx, 1
     mov ecx, msg
     mov edx, msg_len
     int 80h

     mov eax, 1
     xor ebx, ebx
     int 80h

Linked with ld, segfaults. "objdump -h hw8.o" (Nasm's output):

hw8.o:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0000002b  00000000  00000000  00000160  2**4
                   CONTENTS, ALLOC, LOAD, RELOC, CODE
   1 .comment      0000001f  00000000  00000000  00000190  2**0
                   CONTENTS, READONLY

Note that our .text section is not marked READONLY. But after linking:

hw8:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         0000002b  08048080  08048080  00000080  2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .bss          00000000  080490ac  080490ac  000000ab  2**0

   2 .comment      0000001f  00000000  00000000  000000ab  2**0
                   CONTENTS, READONLY

So it looks like ld is doing us dirt - or perhaps Nasm's not "telling it
right". Funny, objdump "gets it" okay...

Still haven't looked at the "elf.inc" macros in asmutils...

Later,
Frank