allocating memory
JohnSmith
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.
Maurizio Vitale
>>>>> "John" == JohnSmith <csne...@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
--
Robert Redelmeier
JohnSmith <csne...@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
>
>
Robert Redelmeier
Maurizio Vitale
<m...@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
Maurizio Vitale
>>>>> "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.
--
Robert Redelmeier
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
James Harris
On 15 Dec, 19:52, Maurizio Vitale <m...@cuma.i-did-not-set--mail-host-
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
robert...@munged.microcosmotalk.com
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.
BGB / cr88192
"James Harris" <james.h...@googlemail.com> wrote in message
news:4b281923$0$5125$9a6e...@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...
Tim Roberts
"BGB / cr88192" <cr8...@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, ti...@probo.com
Providenza & Boekelheide, Inc.