On 27 November 2010 19:29, Brian Harring <email address hidden> wrote:
> Look through linux-user/syscall.c; looks like the flaw is more in do_brk
> itself. Invocations of do_brk *appear* to all assume that it's
> basically brk like in it's behaviour- -1 on failure, else a non-negative
> value of what the size now is.
I think this is wrong. The primary user of do_brk() is the Linux
user system call emulation, so do_brk()'s semantics follow
those of the kernel implemented syscall. (This is different from
those of the brk() library routine, hence the confusion.) That means
it returns the old brk value on failure, not -1. [This is documented
in the NOTES section of the Linux brk(2) manpage, or you can
look at the kernel sources.]
You could argue that this is a bit unhelpful for platform-independent
code like the ARM semihosting routines which end up coding to
an API which might be platform-dependent between linux-user
and some-other-user modes...
On 27 November 2010 19:29, Brian Harring <email address hidden> wrote: syscall. c; looks like the flaw is more in do_brk
> Look through linux-user/
> itself. Invocations of do_brk *appear* to all assume that it's
> basically brk like in it's behaviour- -1 on failure, else a non-negative
> value of what the size now is.
I think this is wrong. The primary user of do_brk() is the Linux
user system call emulation, so do_brk()'s semantics follow
those of the kernel implemented syscall. (This is different from
those of the brk() library routine, hence the confusion.) That means
it returns the old brk value on failure, not -1. [This is documented
in the NOTES section of the Linux brk(2) manpage, or you can
look at the kernel sources.]
You could argue that this is a bit unhelpful for platform- independent
code like the ARM semihosting routines which end up coding to
an API which might be platform-dependent between linux-user
and some-other-user modes...
-- PMM