From: Chuck Crayne on
On Sun, 30 Mar 2008 11:33:18 -0700 (PDT)
ivanatora <ivanatora(a)gmail.com> wrote:

> ; I'm wondering what happens to the memory at 'i' ? Maybe it got
> overwritten with some other exit/status code?

Now that we know that the program is killed before it even starts, the
only thing that commenting or un-commenting an instruction can do is to
change the size and/or alignment of the segments. Therefore Frank's
analysis about the kernel version specific problem with attempting to
zero the rest of the page following the .bss segment is most likely
correct.

To test this, I suggest that you replace the .bss segment with a
writable .data segment.

--
Chuck
http://www.pacificsites.com/~ccrayne/charles.html


From: ivanatora on
Are you suggesting just to replace .bss with .data? Now I understand
how far away I am from assembly :D I thought .bss blocks are for
variables only, while the .data blocks is for constants...
How can the size of the segments be changed?
Btw, I managed to run the program without a kill!
Here is the working code:
-------------------------------------------
section .text
global _start
_test: nop
_start:
nop
_bla:
mov byte [i],50
mov eax, 0x04
mov ebx, 0x01
mov ecx, i
mov edx, 1
int 80H
inc byte [i] ; inc works now!
_bp1: mov eax, 0x04
int 80H

mov eax, 0x01
int 80H
section .data
i resb 4
From: ivanatora on
Btw, the upper code produces an warning:
zagadka.asm:31: warning: uninitialised space declared in non-BSS
section `.data': zeroing


On 31 íÁÒÔ, 00:53, ivanatora <ivanat...(a)gmail.com> wrote:
> Are you suggesting just to replace .bss with .data? Now I understand
> how far away I am from assembly :D I thought .bss blocks are for
> variables only, while the .data blocks is for constants...
> How can the size of the segments be changed?
> Btw, I managed to run the program without a kill!
> Here is the working code:
> -------------------------------------------
> section .text
> global _start
> _test: nop
> _start:
> nop
> _bla:
> mov byte [i],50
> mov eax, 0x04
> mov ebx, 0x01
> mov ecx, i
> mov edx, 1
> int 80H
> inc byte [i] ; inc works now!
> _bp1: mov eax, 0x04
> int 80H
>
> mov eax, 0x01
> int 80H
> section .data
> i resb 4

From: Frank Kotler on
Robert Redelmeier wrote:
> Frank Kotler <fbkotler(a)verizon.net> wrote in part:
>
>>Okay, two bytes, then. Or four... How many bytes is "enough"
>>to cause it to live on a separate page?
>
>
> This should be handled by NASM, ld or exec() from the ELF header.
> AFAIK, in the binary, .bss ought just be visible as brk(), the
> end of the used memory. It might even start in a .data. page.
>
> The canonical order is .text, .rodata, .data, .bss, .stack .
> .text and .rodata can transition on the same 4 kB page,
> as can .data and .bss. Deviate at your peril.

Here's "obdump -x" on Ivan's file, as processed by Nasm:

ivanatora.o: file format elf32-i386
ivanatora.o
architecture: i386, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

Sections:
Idx Name Size VMA LMA File off Algn
0 .bss 00000001 00000000 00000000 00000180 2**2
ALLOC
1 .text 00000046 00000000 00000000 00000180 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
2 .comment 0000001c 00000000 00000000 000001d0 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 ivanatora.asm
00000000 l d .bss 00000000
00000000 l d .text 00000000
00000000 l .bss 00000000 i
0000000c l .text 00000000 bla
00000000 g .text 00000000 _start


RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000002 R_386_32 .bss
00000017 R_386_32 .bss
00000024 R_386_32 .bss
00000034 R_386_32 .bss


.... and after ld gets done with it:

ivanatora: file format elf32-i386
ivanatora
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08048080

Program Header:
LOAD off 0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
filesz 0x000000c6 memsz 0x000000c6 flags r-x
LOAD off 0x000000c8 vaddr 0x080490c8 paddr 0x080490c8 align 2**12
filesz 0x00000000 memsz 0x00000004 flags rw-

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000046 08048080 08048080 00000080 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .bss 00000004 080490c8 080490c8 000000c8 2**2
ALLOC
2 .comment 0000001c 00000000 00000000 000000c8 2**0
CONTENTS, READONLY
SYMBOL TABLE:
08048080 l d .text 00000000
080490c8 l d .bss 00000000
00000000 l d .comment 00000000
00000000 l d *ABS* 00000000
00000000 l d *ABS* 00000000
00000000 l d *ABS* 00000000
00000000 l df *ABS* 00000000 ivanatora.asm
080490c8 l .bss 00000000 i
0804808c l .text 00000000 bla
08048080 g .text 00000000 _start
080490c8 g *ABS* 00000000 __bss_start
080490c8 g *ABS* 00000000 _edata
080490cc g *ABS* 00000000 _end


Looks okay to me...(?). For comparison, here's the .o file from another
assembler (not the same source, obviously):


HelloWorldWithVar.o: file format elf32-i386
HelloWorldWithVar.o
architecture: i386, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x00000000

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000000 00000000 00000000 00000034 2**4
ALLOC, READONLY, CODE
1 .data 00000020 00000000 00000000 00000034 2**4
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .bss 00000000 00000000 00000000 00000054 2**4
ALLOC
3 .text 00000058 00000000 00000000 00000054 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
4 .text 0000000a 00000000 00000000 000000ac 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
5 .data 0000000c 00000000 00000000 000000b6 2**4
CONTENTS, ALLOC, LOAD, DATA
6 .text 00000069 00000000 00000000 000000c2 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
7 .text 00000000 00000000 00000000 0000012b 2**4
ALLOC, READONLY, CODE
SYMBOL TABLE:
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 l d .text 00000000 .text
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .text 00000000 .text
00000000 l d .text 00000000 .text
00000004 g O .data 00000001 MainPgmCoroutine__hla_
00000005 g F .text 00000000 DfltExHndlr__hla_
00000000 g F .text 00000000 _HLAMain
00000000 g F .text 00000000 InstallSignals__hla_
00000000 *UND* 00000000 STDOUT_PUTI32
00000000 *UND* 00000000 DefaultExceptionHandler__hla_
00000000 *UND* 00000000 excepts_install_signals
00000000 *UND* 00000000 BuildExcepts__hla_
00000000 *UND* 00000000 STDOUT_PUTS
00000008 g O .data 00000004 _envp__hla_
00000000 g O .data 00000004 _argc__hla_
00000004 g O .data 00000004 _argv__hla_
00000000 g F .text 00000000 _start


RELOCATION RECORDS FOR [.data]:
OFFSET TYPE VALUE
00000004 R_386_32 .data
00000018 R_386_32 .text


RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000001 R_386_PC32 excepts_install_signals
00000006 R_386_PC32 DefaultExceptionHandler__hla_


RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
0000000e R_386_32 .data
00000017 R_386_32 .data
0000001f R_386_32 .data
00000024 R_386_PC32 BuildExcepts__hla_
0000002e R_386_32 .text
00000033 R_386_PC32 STDOUT_PUTS
00000038 R_386_32 .text
0000003d R_386_PC32 STDOUT_PUTS
00000042 R_386_32 .text
00000047 R_386_PC32 STDOUT_PUTS
0000004d R_386_32 .data
00000052 R_386_PC32 STDOUT_PUTI32
00000057 R_386_32 .text
0000005c R_386_PC32 STDOUT_PUTS


Note the attributes on some of those ".text" sections!!! Amazingly, most
versions of ld make a working executable out of it. But reportedly, at
least one version makes a mess - blocks of zeros in the executable where
there should be code. At least we know why that one segfaults! :)

But that's a distraction from Ivan's problem. I *think* Nasm's doing the
right thing there. Do you see a problem?

Best,
Frank
From: ivanatora on
Mmmkaaay, I reverted back to .bss, and put it on the top of the file,
and put 4 bytes for 'i' back to 1. Everything to the old state. Not
producing any warnings now. I even formed a loop to write the first 10
numbers, and everything is working. Anyway when I remove the loop I
get Killed again. Back into the mystery
------------------------------------------------------------
section .bss
i resb 1
section .text
global _start
_test: nop
_start:
nop
mov byte [i],49
mov esi,10 ; if I remove any of these 3 commented lines the
program get killed. Am I doing some crazy stuff with ESI driving that
program to work on 'magic'?
mov ebx, 0x01
mov ecx, i
mov edx, 1
_bla: mov eax, 0x04
int 80H
inc byte [i]
dec esi ; number two
jnz _bla ; number three

mov eax, 0x01
int 80H
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: Sudoku
Next: Linux distro request