Hi,

Can I allocate memory with 'sub esp, size'? The main program is a
Delphi7 application. There is some manually compiled asm routine in
that.

>>>>> "John" == JohnSmith  <csnews77@MUNGED.microcosmotalk.com> writes:

    John> Hi,

    John> Can I allocate memory with 'sub esp, size'? The main program
    John> is a Delphi7 application. There is some manually compiled asm
    John> routine in that.

On which system?
On bare metal yes. Provided you're sure you're not bumping into your
code or other data structures.
On Unix/Linux no. There're pages below the current stack pointer which
are not mapped to the process.
On Windows I don't know, but I presume you're in the same situation as
Linux.

If you're still working on your threads' stuff, do yourself a favour and
allocate all stacks on the heap. There's no advantages in doing
otherwise.

oth,

        Maurizio


-- 

JohnSmith <csnews77@munged.microcosmotalk.com> wrote in part:
> Can I allocate memory with 'sub esp, size'? The main program
> is a Delphi7 application. There is some manually compiled
> asm routine in that.

Certainly you can legitimately grab some memory (up to stack
size limits).  But stack allocations like this are local --
only persist while the subroutine runs.  When it hits a RET ,
the stack has to be back as it was at subr entry.

The previously grabbed area is on dead stack [ESP-x] which
will get reused, certainly by later CALLs, possibly by userland
signal handlers but not by PM-OS interrupts.


-- Robert



>
>

Maurizio Vitale
<mav@cuma.i-did-not-set--mail-host-address--so-tickle-me.dotsrc.org> wrote in
part:
> On Unix/Linux no. There're pages below the current stack
> pointer which are not mapped to the process.

I just tried a push 40960 bytes lower (10 pages) and got no
segfault on Linux.  Within whatever stack limits, I expect
a decent OS to silently pagefault and map in new pages.

-- Robert

>>>>> "Robert" == Robert Redelmeier <redelm@ev1.net.invalid> writes:

    Robert> Maurizio Vitale
    Robert> <mav@cuma.i-did-not-set--mail-host-address--so-tickle-me.dotsrc.org>
    Robert> wrote in part:
    >> On Unix/Linux no. There're pages below the current stack pointer
    >> which are not mapped to the process.

    Robert> I just tried a push 40960 bytes lower (10 pages) and got no
    Robert> segfault on Linux.  Within whatever stack limits, I expect a
    Robert> decent OS to silently pagefault and map in new pages.

OSes typically check whether the pagefault is within a certain distance
from the current top (bottom) of the stack. If so they extend the stack,
otherwise they raise an exception.

This is the most useful policy, in that it allows the stack to grow
while still catch many memory access errors.

I do not know what that distance is under Linux, but there's certainly a
limit over which you cannot simply move the stack pointer and access
memory there.



-- 

Maurizio Vitale
<mav@cuma.i-did-not-set--mail-host-address--so-tickle-me.dotsrc.org> wrote in
part:
>>>>>> "Robert" == Robert Redelmeier <redelm@ev1.net.invalid> writes:
>    Robert> I just tried a push 40960 bytes lower (10 pages) and got no
>    Robert> segfault on Linux.  Within whatever stack limits, I expect a
>    Robert> decent OS to silently pagefault and map in new pages.
> 
> OSes typically check whether the pagefault is within a certain
> distance from the current top (bottom) of the stack. If so they
> extend the stack, otherwise they raise an exception.
>
> This is the most useful policy, in that it allows the stack to
> grow while still catch many memory access errors.
>
> I do not know what that distance is under Linux, but there's
> certainly a limit over which you cannot simply move the stack
> pointer and access memory there.

Easy:  `unlimit -a` lists limits and `ulimit -s` gets/sets stack.

I just checked, and my system has ulimit -s 8192 KiB .
Push at esp-8192000 ran fine, esp-9000000 segfaulted.

OP's environment may be more limited.

-- Robert

On 15 Dec, 19:52, Maurizio Vitale <m...@cuma.i-did-not-set--mail-host-
address--so-tickle-me.dotsrc.org> wrote:
> >>>>> "Robert" =3D=3D Robert Redelmeier <red...@ev1.net.invalid> writes:
>
> =A0 =A0 Robert> Maurizio Vitale
> =A0 =A0 Robert> <m...@cuma.i-did-not-set--mail-host-address--so-tickle-me=
..dotsrc.org>
> =A0 =A0 Robert> wrote in part:
> =A0 =A0 >> On Unix/Linux no. There're pages below the current stack point=
er
> =A0 =A0 >> which are not mapped to the process.
>
> =A0 =A0 Robert> I just tried a push 40960 bytes lower (10 pages) and got =
no
> =A0 =A0 Robert> segfault on Linux. =A0Within whatever stack limits, I exp=
ect a
> =A0 =A0 Robert> decent OS to silently pagefault and map in new pages.
>
> OSes typically check whether the pagefault is within a certain distance
> from the current top (bottom) of the stack. If so they extend the stack,
> otherwise they raise an exception.
>
> This is the most useful policy, in that it allows the stack to grow
> while still catch many memory access errors.
>
> I do not know what that distance is under Linux, but there's certainly a
> limit over which you cannot simply move the stack pointer and access
> memory there.

You should get hundreds of megabytes, if not thousands. I tried it
once. Can't remember the exact figure but it was large.

To the OP, you should be OK to allocate what you need but remember
that you need to restore the stack pointer before you leave the
function that runs sub esp.

James

On Dec 15, 8:11=A0am, Maurizio Vitale <m...@cuma.i-did-not-set--mail-
host-address--so-tickle-me.dotsrc.org> wrote:
> >>>>> "John" =3D=3D JohnSmith =A0<csnew...@MUNGED.microcosmotalk.com> wri=
tes:
>
> =A0 =A0 John> Hi,
>
> =A0 =A0 John> Can I allocate memory with 'sub esp, size'? The main progra=
m
> =A0 =A0 John> is a Delphi7 application. There is some manually compiled a=
sm
> =A0 =A0 John> routine in that.
>
> On which system?
> On bare metal yes. Provided you're sure you're not bumping into your
> code or other data structures.
> On Unix/Linux no. There're pages below the current stack pointer which
> are not mapped to the process.
> On Windows I don't know, but I presume you're in the same situation as
> Linux.


On Windows, the OS will not extend a stack (by mapping in additional
pages) by more than 4KB at a time (on x86-32 and x86-64 - on IPF it's
8KB).  The approach is to insert stack probes if your local function
allocates more than 4KB of stack space, touching each 4KB that you're
allocating.  Compilers for Windows typically do this automatically,
although some, like MSVC, can turn the behavior off (for example, you
don't need it in a device driver).

Alternatively you could touch the entire stack area at startup.

"James Harris" <james.harris.1@googlemail.com> wrote in message 
news:4b281923$0$5125$9a6e19ea@unlimited.newshosting.com...

On 15 Dec, 19:52, Maurizio Vitale <m...@cuma.i-did-not-set--mail-host-
address--so-tickle-me.dotsrc.org> wrote:
> >>>>> "Robert" == Robert Redelmeier <red...@ev1.net.invalid> writes:
>
> Robert> Maurizio Vitale
> Robert> 
> <m...@cuma.i-did-not-set--mail-host-address--so-tickle-me.dotsrc.org>
> Robert> wrote in part:
> >> On Unix/Linux no. There're pages below the current stack pointer
> >> which are not mapped to the process.
>
> Robert> I just tried a push 40960 bytes lower (10 pages) and got no
> Robert> segfault on Linux. Within whatever stack limits, I expect a
> Robert> decent OS to silently pagefault and map in new pages.
>
> OSes typically check whether the pagefault is within a certain distance
> from the current top (bottom) of the stack. If so they extend the stack,
> otherwise they raise an exception.
>
> This is the most useful policy, in that it allows the stack to grow
> while still catch many memory access errors.
>
> I do not know what that distance is under Linux, but there's certainly a
> limit over which you cannot simply move the stack pointer and access
> memory there.

<--
You should get hundreds of megabytes, if not thousands. I tried it
once. Can't remember the exact figure but it was large.
-->

errm.... no...

hundreds of kB maybe, but not MB... (and sure as hell not thousands of 
MB...).


AFAIK, Windows reserves around 4MB for stacks, and generally has these 
regions set to be guard pages. past this, I think there is usually a region 
of reserved pages (so that a PF will happen if the stack overflows), then, 
there is whatever happens to be mapped in below.

the default load address for EXE's is 0x400000, and I think Windows usually 
puts the stack below the EXE. hence, around 4MB for the stack, then some 
reserved memory (64kB I think, this being essentially "page 0", as 
VirtualAlloc seems to use 64kB blocks).

hence, if one overflows the thread-0 stack, it hits the 0 page, or tries to 
wrap around into kernel space.

dunno much how it works on Linux exactly, as I have not looked into this so 
much.


<--
To the OP, you should be OK to allocate what you need but remember
that you need to restore the stack pointer before you leave the
function that runs sub esp.
-->

and keep it "sane", since, no, you infact can't do a 256MB or 1GB alloc 
simply by subtracting the stack pointer...

actually, it is not really "safe" much beyond 10s of kB, as then one puts 
themselves in major risk of stack overflows if there happen to be a number 
of such frames on the stack...

"BGB / cr88192" <cr88192@MUNGED.microcosmotalk.com> wrote:
>
>hundreds of kB maybe, but not MB... (and sure as hell not thousands of 
>MB...).
>>
>AFAIK, Windows reserves around 4MB for stacks, and generally has these 
>regions set to be guard pages. past this, I think there is usually a region 
>of reserved pages (so that a PF will happen if the stack overflows), then, 
>there is whatever happens to be mapped in below.

Yes.  ESP sits at the end of allocated space, and above that is reserved
space (which generates a page fault that allocates more memory).  The stack
reservation size and initial stack allocation size are both parameters in
the PE executable header.  VC++ defaults to 64kB allocation and 1MB
reservation, but both are easily changable via a linker parameter.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.