Current break round up

Current break round up

[Kircsi Tibor]

Hi,

Sorry for my english. I started learn assembly again after 15 years.
Now, I'm learning about memory management and sys_brk system call. I've
created a really simple program, which try to extend the heap size. I've
read, when sys_brk is called with the new break address(last usable
address of the heap or data segment), it will be rounded up to the next
nearest page, but it didn't. Am I misundestand somthing?

# meminf.s
# 2008.09.25.
# PURPOSE: Test current_break address round up at sys_brk call

.include "../sharedlibs/linux.s"

.section .text
        .globl  _start
_start:
        movl    %esp, %ebp

        movl    $0, %ebx                # %ebx = 0, get the current
curret_break
        movl    $SYS_BRK, %eax
        int     $INT                    # %eax = address of
current_break

        addl    $0x1002, %eax           # add 4098 to current
current_break
        movl    %eax, %ebx              # %ebx = the address of the new
current_break
        movl    $SYS_BRK, %eax
        int     $INT

        movl    $0, %ebx                # set the return value of the
program
        movl    $SYS_EXIT, %eax
        int     $INT

regards,
Kiri

Re: Current break round up

[Frank Kotler]

Kircsi Tibor wrote:
> Hi,
> 
> Sorry for my english. I started learn assembly again after 15 years.
> Now, I'm learning about memory management and sys_brk system call. I've
> created a really simple program, which try to extend the heap size. I've
> read, when sys_brk is called with the new break address(last usable
> address of the heap or data segment), it will be rounded up to the next
> nearest page, but it didn't. Am I misundestand somthing?

I've noticed this. Seems to be related to kernel version (2.4.33.3 
here). May be a "bug"? I think you can access memory up to the top of 
the page (what you/we would "expect" brk to return). I don't know what 
to make of it.

Best,
Frank

Re: Current break round up

[Tibor Kircsi]

Hi,

You're right! I tested it and I could write and read above the current
break after I call brk. I'll will test the page border too. Thanks.

regards,
Tibor

On Wed, Oct 1, 2008 at 3:43 PM, Frank Kotler <fbkotler@verizon.net> wrote:
>
> Kircsi Tibor wrote:
>>
>> Hi,
>>
>> Sorry for my english. I started learn assembly again after 15 years.
>> Now, I'm learning about memory management and sys_brk system call. I've
>> created a really simple program, which try to extend the heap size. I've
>> read, when sys_brk is called with the new break address(last usable
>> address of the heap or data segment), it will be rounded up to the next
>> nearest page, but it didn't. Am I misundestand somthing?
>
> I've noticed this. Seems to be related to kernel version (2.4.33.3 here). May be a "bug"? I think you can access memory up to the top of the page (what you/we would "expect" brk to return). I don't know what to make of it.
>
> Best,
> Frank
>

Re: Current break round up

[Frank Kotler]

Randall Hyde wrote:
> Almost everything I've read about SYS_BRK says "don't use it."  It's an obsolete memory-management technique that has been left in the kernel to support legacy code. I'm not at all surprised to find that it isn't being maintained as well as it should as the kernel developers probably don't even think about it anymore. The correct way to do memory management under *NIX is to use anonymous memory-mapped files.

Dunno what you've been reading. Reading the output of "strace" gives me 
a different impression. For example, "strace hla" reads like so:

execve("/usr/hla/hla", ["hla"], [/* 37 vars */]) = 0
uname({sys="Linux", node="reltok1", ...}) = 0
brk(0)                                  = 0x80ba544
brk(0x80db544)                          = 0x80db544
brk(0x80dc000)                          = 0x80dc000
write(2, "Usage: hla options filename(s)\n\n"..., 199Usage: hla options 
filename(s)

HLA (High Level Assembler - GAS back end, LD linker)
Version 1.103 build 20424 (prototype)

   -?        Display help message.
   -license  Display license information.
) = 199
exit_group(1)                           = ?
Process 14016 detached

(note, Kircsi, the unaligned return until the third call)

'Course, ya can never tell what those high-level languages are gonna do! :)

Best,
Frank

Re: Current break round up

[Kircsi Tibor]

Hi,

I may have misunderstood what you wrote, but I took a probe: (debugged
with cgdb)

.include "../sharedlibs/linux.s"

.section .text
        .globl  _start
_start:
        movl    %esp, %ebp

        # 1st brk call
        movl    $0, %ebx                # %ebx = 0, get the current
curret_break
        movl    $SYS_BRK, %eax
        int     $INT                    # %eax = address of
current_break

        # 2nd brk call
        addl    $0x1002, %eax           # add 4098 to current
current_break
        movl    %eax, %ebx              # %ebx = the address of the new
current_break
        movl    $SYS_BRK, %eax
        int     $INT

        # 3rd brk call
        movl    $0, %ebx
        movl    $SYS_BRK, %eax
        int     $INT

        # 4th brk call
        movl    $SYS_BRK, %eax
        int     $INT

        # 5th brk call
        movl    $SYS_BRK, %eax
        int     $INT

        # sys_exit
        movl    $0, %ebx                # set the return value of the
program
        movl    $SYS_EXIT, %eax
        int     $INT

addresses:
1st - 0x8049000 it's OK, because linux loads programs into the 0x8048000
virtual address space, so this is the first page
2nd - 0x804a002 not aligned to 0x804b000
3rd - 0x804a002 same
4th - same
5th - same

That's ok, after the 2nd brk I just always ask for the current break
with %ebx = 0. So, it seems unaligned return after the 4th call too.

regards,
Tibor

On Wed, 2008-10-01 at 14:22 -0400, Frank Kotler wrote:
> Randall Hyde wrote:
> > Almost everything I've read about SYS_BRK says "don't use it."  It's an obsolete memory-management technique that has been left in the kernel to support legacy code. I'm not at all surprised to find that it isn't being maintained as well as it should as the kernel developers probably don't even think about it anymore. The correct way to do memory management under *NIX is to use anonymous memory-mapped files.
> 
> Dunno what you've been reading. Reading the output of "strace" gives me 
> a different impression. For example, "strace hla" reads like so:
> 
> execve("/usr/hla/hla", ["hla"], [/* 37 vars */]) = 0
> uname({sys="Linux", node="reltok1", ...}) = 0
> brk(0)                                  = 0x80ba544
> brk(0x80db544)                          = 0x80db544
> brk(0x80dc000)                          = 0x80dc000
> write(2, "Usage: hla options filename(s)\n\n"..., 199Usage: hla options 
> filename(s)
> 
> HLA (High Level Assembler - GAS back end, LD linker)
> Version 1.103 build 20424 (prototype)
> 
>    -?        Display help message.
>    -license  Display license information.
> ) = 199
> exit_group(1)                           = ?
> Process 14016 detached
> 
> (note, Kircsi, the unaligned return until the third call)
> 
> 'Course, ya can never tell what those high-level languages are gonna do! :)
> 
> Best,
> Frank
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Current break round up

[Frank Kotler]

Kircsi Tibor wrote:
> Hi,
> 
> I may have misunderstood what you wrote, but I took a probe: (debugged
> with cgdb)
> 
> .include "../sharedlibs/linux.s"
> 
> .section .text
>         .globl  _start
> _start:
>         movl    %esp, %ebp
> 
>         # 1st brk call
>         movl    $0, %ebx                # %ebx = 0, get the current
> curret_break
>         movl    $SYS_BRK, %eax
>         int     $INT                    # %eax = address of
> current_break
> 
>         # 2nd brk call
>         addl    $0x1002, %eax           # add 4098 to current
> current_break
>         movl    %eax, %ebx              # %ebx = the address of the new
> current_break
>         movl    $SYS_BRK, %eax
>         int     $INT
> 
>         # 3rd brk call
>         movl    $0, %ebx
>         movl    $SYS_BRK, %eax
>         int     $INT
> 
>         # 4th brk call
>         movl    $SYS_BRK, %eax
>         int     $INT
> 
>         # 5th brk call
>         movl    $SYS_BRK, %eax
>         int     $INT
> 
>         # sys_exit
>         movl    $0, %ebx                # set the return value of the
> program
>         movl    $SYS_EXIT, %eax
>         int     $INT
> 
> addresses:
> 1st - 0x8049000 it's OK, because linux loads programs into the 0x8048000
> virtual address space, so this is the first page
> 2nd - 0x804a002 not aligned to 0x804b000
> 3rd - 0x804a002 same
> 4th - same
> 5th - same
> 
> That's ok, after the 2nd brk I just always ask for the current break
> with %ebx = 0. So, it seems unaligned return after the 4th call too.

Hi Tibor,
(sorry I called you "Kircsi")
I didn't mean that sys_brk aligned itself "automatically" by repeated 
calls. I ASSume that, unseen in the "strace" output, %ebx is being 
aligned "by hand" to a page boundary before that last sys_brk.

>> Randall Hyde wrote:

BTW, Randy, I ASSumed that you intended to reply to the list. Ya gotta 
hit "reply all" or it goes just to the sender...

I don't disagree that sys_mmap (or sys_mmap2?) is a better bet for 
allocating memory, but it isn't much use for "exploring" sys_brk...

Best,
Frank

Re: Current break round up

[Tibor Kircsi]

Hi Frank,

Thanks. I think, I understand. But, It is a question yet, it is a bug
or by design, that sys_brk doesn't round up current break to page
boundary. I'll try and inspect how sys_mmap works.

Thanks for your suggestion.

regards,
Tibor

On Wed, Oct 1, 2008 at 10:27 PM, Frank Kotler <fbkotler@verizon.net> wrote:
> Kircsi Tibor wrote:
>>
>> Hi,
>>
>> I may have misunderstood what you wrote, but I took a probe: (debugged
>> with cgdb)
>>
>> .include "../sharedlibs/linux.s"
>>
>> .section .text
>>        .globl  _start
>> _start:
>>        movl    %esp, %ebp
>>
>>        # 1st brk call
>>        movl    $0, %ebx                # %ebx = 0, get the current
>> curret_break
>>        movl    $SYS_BRK, %eax
>>        int     $INT                    # %eax = address of
>> current_break
>>
>>        # 2nd brk call
>>        addl    $0x1002, %eax           # add 4098 to current
>> current_break
>>        movl    %eax, %ebx              # %ebx = the address of the new
>> current_break
>>        movl    $SYS_BRK, %eax
>>        int     $INT
>>
>>        # 3rd brk call
>>        movl    $0, %ebx
>>        movl    $SYS_BRK, %eax
>>        int     $INT
>>
>>        # 4th brk call
>>        movl    $SYS_BRK, %eax
>>        int     $INT
>>
>>        # 5th brk call
>>        movl    $SYS_BRK, %eax
>>        int     $INT
>>
>>        # sys_exit
>>        movl    $0, %ebx                # set the return value of the
>> program
>>        movl    $SYS_EXIT, %eax
>>        int     $INT
>>
>> addresses:
>> 1st - 0x8049000 it's OK, because linux loads programs into the 0x8048000
>> virtual address space, so this is the first page
>> 2nd - 0x804a002 not aligned to 0x804b000
>> 3rd - 0x804a002 same
>> 4th - same
>> 5th - same
>>
>> That's ok, after the 2nd brk I just always ask for the current break
>> with %ebx = 0. So, it seems unaligned return after the 4th call too.
>
> Hi Tibor,
> (sorry I called you "Kircsi")
> I didn't mean that sys_brk aligned itself "automatically" by repeated calls.
> I ASSume that, unseen in the "strace" output, %ebx is being aligned "by
> hand" to a page boundary before that last sys_brk.
>
>>> Randall Hyde wrote:
>
> BTW, Randy, I ASSumed that you intended to reply to the list. Ya gotta hit
> "reply all" or it goes just to the sender...
>
> I don't disagree that sys_mmap (or sys_mmap2?) is a better bet for
> allocating memory, but it isn't much use for "exploring" sys_brk...
>
> Best,
> Frank
>
>
>