Linux-Development-Sys Digest #174, Volume #8 Tue, 26 Sep 00 13:13:12 EDT
Contents:
Re: Linux Stack Sizes? (0/1)
Re: Kernel 2.4.0-test8 hang at boot (Tom Herman)
Re: Linux Stack Sizes? (0/1) (Johan Kullstam)
serial port problem from module (Gilles Riffaud)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
LinuxThreads and SIGVTALRM (Fro-Man)
Re: Linux Stack Sizes? (0/1) (Andi Kleen)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
Re: Linux Stack Sizes? (0/1) (MeekGeek)
Re: Linux Stack Sizes? (0/1) (Pete Zaitcev)
----------------------------------------------------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: 26 Sep 2000 13:42:26 GMT
The problem is the first time you access a stack page
causing page fault, kernel will see if %esp is nearby:
(/usr/src/linux/arch/i386/mm/fault.c, do_page_fault())
/*
* accessing the stack below %esp is always a bug.
* The "+ 32" is there due to some instructions (like
* pusha) doing post-decrement on the stack and that
* doesn't show up until later..
*/
if (address + 32 < regs->esp)
goto bad_area;
One solution is to call a function like
void AllocStack(int size)
{
memset(alloca(size),0,size);
}
before calling TouchAllStack.
MeekGeek <[EMAIL PROTECTED]> wrote:
> On Tue, 26 Sep 2000 02:10:10 GMT, MeekGeek <[EMAIL PROTECTED]>
> wrote:
>>I develop a large server application that we're in the process of
>>porting to Solaris and Linux. To make this story short, let's just
>>say I need to partition the program stack for my own needs.
>>
>>I found that I only had access to a little more than 6K before my
>>program would crash, SIGSEGV. It's as if I'm only getting an 8K
>>stack, fixed, with the system/compiler/runtime lib using about 1500
>>bytes by the time I get to main().
>>
>>I started factoring out code to narrow it down, and was left with a
>>simple test program. I will include that below.
>>
>>I need LOTS of stack. We have a cross-platform non-preemptive kernel
>>(coroutine package) that allocates "task" stacks from the main
>>program's stack. Therefore, it is the sum of many, possible 1000 or
>>more, tasks' stacks. These stacks are typically 20-30K each.
>>
>>The machine can be assumed to be dedicated to running this server
>>application, and can be assumed to have at least 1GB of physical RAM.
>>But I need a chunk of that for stacks (perhaps 50MB). All I can seem
>>to get under Linux, with a GCC 2.95.2 build, is about 6.5KB for stack.
>>
>>Is there a linker option, compiler directive, executable editor, or
>>something similar, that will allow me to specify a larger stack?
>>There must be some way for me to get more than 6K of usable stack
>>space! :-)
> Okay, I found the rlimit stuff, including
> getrlimit/setrlimit(RLIMIT_STACK, ...). I modified my test program to
> call getrlimit, which returned a soft limit of 16MB and a hard limit
> of RLIM_INFINITY. Since it was reporting a soft limit of 16MB, and I
> was seeing about 8K, I figured setting the limit to RLIM_INFINITY was
> pointless, but I tried it anyway. It was. It still stops printing
> messages at about 6.5 K. I set the TOUCH incremental value in my test
> program to only 8 bytes and repeated it, and it got to 6912 and core
> dumped with a SEGV.
> So that limit seems to be getting ignored too.
> Any ideas?
> M.
>>Does Linux support the "guard pages" concept implemented by NT on
>>Intel processors?
>>
>>One other idea I had was to use PThreads to create a new thread,
>>presumable specifying a large stack at thread creation time, if that's
>>possible from PThreads. Then have it allocate the task stacks from
>>its large thread stack.
>>
>>Anyhow, the following program crashes if I specify anything more than
>>about 6K, such as the default if you just run it. Also attached with
>>a makefile.
>>
>>Thanks,
>>M
>>
>>========================================================
>>
>>#include <stdio.h>
>>#include <stdlib.h>
>>#include <string.h>
>>
>>#define TOUCHSIZE 1024
>>static char * TouchAllStack(unsigned long size)
>>{
>> char c;
>> static char * p = &c;
>> static unsigned long totalsize = size;
>>
>> p = (char *) (((unsigned long)p) & ~7); // 8-byte align
>>
>> printf("Allocating %ul bytes from stack ending at: %08X\n",
>> size, (unsigned long) p);
>>
>> do {
>> p -= TOUCHSIZE;
>> // Now, check access to stack memory
>> // and reference guard pages (Windows).
>> c = *p; // try reading
>> *p = c; // try writing
>> printf("Touched %lu bytes of stack at address:
>>%08X\n",
>> totalsize-size+TOUCHSIZE, (unsigned long) p);
>> } while ((size -= TOUCHSIZE) >= TOUCHSIZE);
>>
>> p -= TOUCHSIZE; // round down to next complete TOUCHSIZE bytes
>> memset(p,0,size);
>> return p;
>>}
>>
>>#define DEFAULT_STACK (256*1024UL)
>>#define MIN_STACK 8192UL // 16384UL
>>int main(int argc, char *argv[])
>>{
>> char * pStack = NULL;
>> int rc;
>>
>> unsigned long MaxStack = DEFAULT_STACK;
>>
>> if (argc > 1)
>> MaxStack=(unsigned long) atol(argv[1]);
>> if (MaxStack < MIN_STACK)
>> MaxStack = DEFAULT_STACK;
>>
>> pStack = TouchAllStack(MaxStack);
>>
>> return 0;
>>}
------------------------------
Date: Tue, 26 Sep 2000 10:46:15 -0400
From: Tom Herman <[EMAIL PROTECTED]>
Subject: Re: Kernel 2.4.0-test8 hang at boot
The new kernel seems less forgiving of hardware mismatches than older
kernels.
Maybe because I'm running older hardware, or there are so many new
choices
for hardware in this kernel. I got the same boot message. I had to
fiddle with
the 'make xconfig' default values until I got the correct drivers
configured.
I'm still working on getting my remaining hardware working.
"Frank M. Krauss" wrote:
> I'm attempting to update my Linux System to the Latest Kernel
> I downloaded and installed Kernel 2.4.0-test8.
> After running <make zdisk> I attempted to boot with the Floppy disk.
> It just ran for a moment and then sat there.
>
> When I attempted to Boot the new Kernel through LILO, I got the
> following data on the Screen:
> boot:
> Loading Linux .......
> <at this point, the system just Hangs,
> I never got the Uncompressing Linux message>
>
> My System is a Compaq Deskpro 66M with 24 Mb of Ram.
> The Processor is a I486DX2.
> The version of LILO I have is 20.
>
> Thanking everyone for any Help that I can get to solve this Problem.
>
> Yours truly,
>
> Frank Krauss
--
Tom Herman
Charleston, SC
[EMAIL PROTECTED]
------------------------------
Subject: Re: Linux Stack Sizes? (0/1)
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 26 Sep 2000 11:03:35 -0400
"Paul D. Smith" <[EMAIL PROTECTED]> writes:
> This is not a problem with the maximum size of the stack.
>
> This is a problem with your code.
>
> This isn't even _remotely_ close to being a valid C program. I'm
> actually surprised it lasts as long as it does (6K) before it crashes.
>
> Where are you porting this _from_ that it actually works as you have it
> written?
>
> First, you are assuming that the stack lives in high memory and grows
> towards low memory. You cannot assume that. There is absolutely no
> reason the stack couldn't live in low memory, and grow upwards. Many
> implementations of UNIX and other OSs do exactly this.
>
> Heck, there's no reason (from a C standard point of view) the stack
> couldn't live right smack dab in the middle of the memory space, and
> grow randomly in both directions. I don't know of any that do this, but
> it's legal. To be pedantic, there's no guarantee that you even _have_ a
> stack in the C standard, and some implementations don't (as such).
>
> Second, you are assuming that any memory below your stack can
> arbitrarily be written on. That's totally broken. The stack could
> well be allocated only as needed by function calls, and memory beyond
> what's been used is simply not available (hence traps if you try to
> access it).
>
> You will have to write a valid C program to make this work. The
> simplest and most portable way is to use the heap (malloc) instead of
> the stack. I'm really not clear on why you must use the stack instead
> of the heap; memory is memory is memory. With sizes as large as you
> seem to want surely the overhead of invoking malloc() once is completely
> negligible.
>
> If you _must_ have it in the stack, you're going to have to actually
> _allocate_ that much stack! You can't simply use it without previously
> telling the compiler and/or runtime system you will need it.
>
> For example, you could use alloca(). This smells like malloc(), but it
> allocates memory from the stack instead of the heap (no free()
> necessary). While this isn't a standard C function, it's supported by
> GCC which runs on almost any UNIX system.
btw alloca has been broken for the latest versions of gcc (like
2.95.x). they may have fixed this, but it can't hurt to check.
just allocate a vector using a variable rather than a
constant and gcc will magically do the right thing. do it like this
int foo(
int n)
{
double vec[n];
*do stuff*
return 0;
}
instead of
int foo(
int n)
{
double *vec = alloca(sizeof(double)*n);
*do stuff*
return 0;
}
since the former works but the latter fails.
> Also, most other UNIX
> compilers and OS's support it (certainly Solaris does, even if you use
> SPARCWorks instead of GCC). There _are_ platforms that don't (can't)
> support alloca(), however.
>
> If you can't do that, and your compiler supports the 1999 ISO C
> standard, you can use variable size arrays (even though this is standard
> and alloca() isn't, I still list alloca() as more portable because not
> too many compilers support 1999 ISO C yet, while almost all support
> alloca()). GCC supports these, although I'm not sure if they are 100%
> standard yet. They're standard enough for you; there just may be some
> weird corner cases that are non-standard.
>
> If you can't do that, you will have to provide some kind of maximum
> static value for the size of the array and just fail if you need more
> than that.
>
> If you can't do any of those things, AFAICT you're SOL and you can't
> port your program to UNIX, or probably most any other platform. Sorry.
>
> --
> -------------------------------------------------------------------------------
> Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
> "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
> -------------------------------------------------------------------------------
> These are my opinions---Nortel Networks takes no responsibility for them.
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
sysengr
------------------------------
From: Gilles Riffaud <[EMAIL PROTECTED]>
Subject: serial port problem from module
Date: Tue, 26 Sep 2000 17:36:48 +0200
I am writing a module that send and receive data to a device via serial
port. How can I configure the serial port: baud rate,parity,stopbit..
from my module
the module open the serial port (/dev/ttyS0) with the filp_open()
function returns a pointer for file structure (struct file *) that
contains functions pointer to read,write,ioctl..
But when I call the ioctl() function to set termios parameters It return
EFAULT error: because the function must be call by user mode program and
not kernel mode.
How can I do this from my module in kernel mode?
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 16:07:08 GMT
First, regardless of how defensive I get below, I'd like to thank you
for your response. The alloca() comment was a good hint at what the
problem was, although it didn't really crystalize until "jo" replied
later about the ESP kernel check.
On 26 Sep 2000 00:17:35 -0400, "Paul D. Smith"
<[EMAIL PROTECTED]> wrote:
>This is not a problem with the maximum size of the stack.
>
>This is a problem with your code.
No, actually, as it turns out, it's essentially the Linux kernel
assuming a standard C stack frame, with ESP being below the address
being referenced.
>This isn't even _remotely_ close to being a valid C program. I'm
>actually surprised it lasts as long as it does (6K) before it crashes.
What makes you think there's any requirement for it to be a valid _C_
program?
>Where are you porting this _from_ that it actually works as you have it
>written?
MacOS 6/7/8/9, Windows 9x/Me/NT/2000, Solaris 2.5x and up.
>First, you are assuming that the stack lives in high memory and grows
>towards low memory. You cannot assume that. There is absolutely no
>reason the stack couldn't live in low memory, and grow upwards. Many
>implementations of UNIX and other OSs do exactly this.
I'm not writing completely cross-platform C-only code. It's 95%
platform-independent, so all I need to port each time are 4 simple
functions, typically using a little inline assembler: Get/SetSP, and
Save/Restore Context. You will find this is typical of coroutine
packages, as well as thread packages in general.
>Heck, there's no reason (from a C standard point of view) the stack
>couldn't live right smack dab in the middle of the memory space, and
>grow randomly in both directions. I don't know of any that do this, but
>it's legal. To be pedantic, there's no guarantee that you even _have_ a
>stack in the C standard, and some implementations don't (as such).
Sigh. I was hoping for a _practical_ response... :-) This is a
Linux/Intel implementation. I already have an Intel implementation.
The stack grows down! Not down maybe. Down. Yes, I can write my own
compiler or program that uses the stack memory in a different way, and
in fact that's what I've done and you're complaining is invalid in
some way.
>Second, you are assuming that any memory below your stack can
>arbitrarily be written on. That's totally broken. The stack could
>well be allocated only as needed by function calls, and memory beyond
>what's been used is simply not available (hence traps if you try to
>access it).
I'm assuming that there is a stack, and that I can push data onto it
and pop data from it. That I can choose to do so using a reasonably
large size, such as 1K at a time. That there is no small limit (like
8K) to how much stack I can use, or that there is a way to increase
that from the default. That's all I'm assuming. It is valid to be
able to read and write the memory below your current stack position.
That's what PUSH does, and that's how C compilers allocate automatic
(stack) variables. There's nothing wrong with that. As it turns out,
the Linux kernel requires you to decrement the stack pointer BEFORE
the memory reference. That's the issue here (thanks jo).
>You will have to write a valid C program to make this work. The
>simplest and most portable way is to use the heap (malloc) instead of
>the stack. I'm really not clear on why you must use the stack instead
>of the heap; memory is memory is memory. With sizes as large as you
>seem to want surely the overhead of invoking malloc() once is completely
>negligible.
Yes, there are _alternate_ allocation strategies -- I wanted to know
what was wrong with using stack. My NT implementation pretty much
required stack, since there were times when it felt it was invalid to
have ESP pointing into a dynamically-allocated heap block. Use of
stack, rather than heap for stack, was pretty universally accepted.
:-) So I changed the implementation to use the mainline's stack for
individual task stacks. This has been fine on all the other OSes.
>If you _must_ have it in the stack, you're going to have to actually
>_allocate_ that much stack! You can't simply use it without previously
>telling the compiler and/or runtime system you will need it.
C compilers do just that. They don't call alloca() on each function
call. Instead, they just push the arguments and use the stack memory.
>For example, you could use alloca(). This smells like malloc(), but it
>allocates memory from the stack instead of the heap (no free()
>necessary). While this isn't a standard C function, it's supported by
>GCC which runs on almost any UNIX system. Also, most other UNIX
>compilers and OS's support it (certainly Solaris does, even if you use
>SPARCWorks instead of GCC). There _are_ platforms that don't (can't)
>support alloca(), however.
This is more like the info I was looking for. The fact that alloca()
even exists is a hint that there's a way that's supported by the
compiler. (Note that anything implemented by the compiler or runtime
library could be done directly in my code and still be valid.
Sometimes you must know about the implementation to achieve a goal.
Generating stack tracebacks for example. And the coroutine package
itself.
>-------------------------------------------------------------------------------
> Paul D. Smith <[EMAIL PROTECTED]> Network Management Development
> "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
>-------------------------------------------------------------------------------
> These are my opinions---Nortel Networks takes no responsibility for them.
Hey, I used to work at NorTel too. BNR before that. Back before it
was called NorTel though. From '84 to '89. :-)
Anyhow, in the midst of all that, I see your point. Some piece of
code (in this case, the page fault handler) is unhappy with my
references to stack below the SP. If I had just coded it for real,
instead of using the test program, I might have not had a problem,
since of course the coroutine package sets SP before it restores the
context and let's the task run.
Thanks for your reply.
M.
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 16:08:08 GMT
On Tue, 26 Sep 2000 13:24:30 +0200, Rimas <[EMAIL PROTECTED]>
wrote:
>MeekGeek wrote:
>> // Now, check access to stack memory
>> // and reference guard pages (Windows).
>> c = *p; // try reading
>> *p = c; // try writing
>
>Check out the assembler output (-S).
>This code is 'optimized out' by compiler. Try to compile without
>optimization or use something like
> *p=*p+1;
>or
> *p++;
>
>to prevent optimization.
It's not being optimized out. It's crashing on the memory dereference
afterall... :-)
But thanks for taking the time to help,
M.
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 16:11:04 GMT
On Tue, 26 Sep 2000 13:42:59 +0200, James Avery <[EMAIL PROTECTED]> wrote:
>On Tue, 26 Sep 2000, MeekGeek wrote:
>
>> Anyhow, the following program crashes if I specify anything more than
>> about 6K, such as the default if you just run it. Also attached with
>> a makefile.
>
>Hi,
>
>Why do you want to use the stack, which is rather volatile, rather than
>use a calloc() allocated memory area?
Because the memory will be used as stack memory, by a series of
"tasks" beyond my control (via the coroutine package). Also, because
under NT, I had problems with the NT system finding ESP pointing to
somewhere outside what it thought was the only valid stack area for my
code.
In both the NT case and the Linux case (as we see from jo's reply), my
problem comes from the OS being too clever for me. I have to make the
OS feel better about allowing this legal use of memory.
M.
------------------------------
From: Fro-Man <[EMAIL PROTECTED]>
Subject: LinuxThreads and SIGVTALRM
Date: Tue, 26 Sep 2000 12:05:06 -0400
With LinuxThreads will SIGVTALRM (which is supposed to be the ammount of
execution time out of kernel space, I think) be all the combined execution
time of the process (all threads) or will it just be the execution time of
the thread that called setittimer()?
# Aaron Day # [EMAIL PROTECTED] # http://www.csis.gvsu.edu/~daya #
That which doesn't kill us, sure as hell hurts a lot...
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: 26 Sep 2000 17:48:07 +0200
Rimas <[EMAIL PROTECTED]> writes:
> Check out the assembler output (-S).
> This code is 'optimized out' by compiler. Try to compile without
> optimization or use something like
> *p=*p+1;
> or
> *p++;
>
> to prevent optimization.
That's of course a rather bogus way to prevent optimization (it may work
in some gcc versions, but is definitely not something you should depend
on)
The C standard sanctionized way is to use volatile pointers.
-Andi
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 16:20:49 GMT
On 26 Sep 2000 13:42:26 GMT, <[EMAIL PROTECTED]> wrote:
>The problem is the first time you access a stack page
>causing page fault, kernel will see if %esp is nearby:
>
>(/usr/src/linux/arch/i386/mm/fault.c, do_page_fault())
>
> /*
> * accessing the stack below %esp is always a bug.
> * The "+ 32" is there due to some instructions (like
> * pusha) doing post-decrement on the stack and that
> * doesn't show up until later..
> */
> if (address + 32 < regs->esp)
> goto bad_area;
Oh my... THANK YOU! I'm going to have to get used to this idea that
under Linux, the OS source code is available. :-)
This is obviously the problem. I was "out-clevered" by an extra
kernel check. :-) Yes, there's nothing wrong with that check really.
It does assume that ESP will be decremented _before_ the use, which is
probably a _little_ on the false assumption side, but no more so than
using the stack before the decrement would be. :-)
I think it's a safe, and good, idea to update my code to ensure that I
always decrement the stack pointer _prior_ to any reference. In
addition to getting past the check above, it's also just better code.
I believe this is what Paul Smith was trying to explain.
>One solution is to call a function like
>
>void AllocStack(int size)
>{
> memset(alloca(size),0,size);
>}
>
>before calling TouchAllStack.
I don't actually really have to call TouchAllStack at all. That was
only there to validate that my tasks created would actually have
access to their full range of stack memory. I didn't want to have the
tasks fire up and start running and then see a crash on a task swap
due to the new task's stack area not being valid.
But I believe I can use this to ensure that this memory can in fact be
accessed by all of the tasks.
Thank you very much.
I believe I have my answer.
M.
______________-
>MeekGeek <[EMAIL PROTECTED]> wrote:
>> On Tue, 26 Sep 2000 02:10:10 GMT, MeekGeek <[EMAIL PROTECTED]>
>> wrote:
>
>>>I develop a large server application that we're in the process of
>>>porting to Solaris and Linux. To make this story short, let's just
>>>say I need to partition the program stack for my own needs.
>>>
>>>I found that I only had access to a little more than 6K before my
>>>program would crash, SIGSEGV. It's as if I'm only getting an 8K
>>>stack, fixed, with the system/compiler/runtime lib using about 1500
>>>bytes by the time I get to main().
>>>
>>>I started factoring out code to narrow it down, and was left with a
>>>simple test program. I will include that below.
>>>
>>>I need LOTS of stack. We have a cross-platform non-preemptive kernel
>>>(coroutine package) that allocates "task" stacks from the main
>>>program's stack. Therefore, it is the sum of many, possible 1000 or
>>>more, tasks' stacks. These stacks are typically 20-30K each.
>>>
>>>The machine can be assumed to be dedicated to running this server
>>>application, and can be assumed to have at least 1GB of physical RAM.
>>>But I need a chunk of that for stacks (perhaps 50MB). All I can seem
>>>to get under Linux, with a GCC 2.95.2 build, is about 6.5KB for stack.
>>>
>>>Is there a linker option, compiler directive, executable editor, or
>>>something similar, that will allow me to specify a larger stack?
>>>There must be some way for me to get more than 6K of usable stack
>>>space! :-)
>
>
>> Okay, I found the rlimit stuff, including
>> getrlimit/setrlimit(RLIMIT_STACK, ...). I modified my test program to
>> call getrlimit, which returned a soft limit of 16MB and a hard limit
>> of RLIM_INFINITY. Since it was reporting a soft limit of 16MB, and I
>> was seeing about 8K, I figured setting the limit to RLIM_INFINITY was
>> pointless, but I tried it anyway. It was. It still stops printing
>> messages at about 6.5 K. I set the TOUCH incremental value in my test
>> program to only 8 bytes and repeated it, and it got to 6912 and core
>> dumped with a SEGV.
>
>> So that limit seems to be getting ignored too.
>
>> Any ideas?
>
>> M.
>
>>>Does Linux support the "guard pages" concept implemented by NT on
>>>Intel processors?
>>>
>>>One other idea I had was to use PThreads to create a new thread,
>>>presumable specifying a large stack at thread creation time, if that's
>>>possible from PThreads. Then have it allocate the task stacks from
>>>its large thread stack.
>>>
>>>Anyhow, the following program crashes if I specify anything more than
>>>about 6K, such as the default if you just run it. Also attached with
>>>a makefile.
>>>
>>>Thanks,
>>>M
>>>
>>>========================================================
>>>
>>>#include <stdio.h>
>>>#include <stdlib.h>
>>>#include <string.h>
>>>
>>>#define TOUCHSIZE 1024
>>>static char * TouchAllStack(unsigned long size)
>>>{
>>> char c;
>>> static char * p = &c;
>>> static unsigned long totalsize = size;
>>>
>>> p = (char *) (((unsigned long)p) & ~7); // 8-byte align
>>>
>>> printf("Allocating %ul bytes from stack ending at: %08X\n",
>>> size, (unsigned long) p);
>>>
>>> do {
>>> p -= TOUCHSIZE;
>>> // Now, check access to stack memory
>>> // and reference guard pages (Windows).
>>> c = *p; // try reading
>>> *p = c; // try writing
>>> printf("Touched %lu bytes of stack at address:
>>>%08X\n",
>>> totalsize-size+TOUCHSIZE, (unsigned long) p);
>>> } while ((size -= TOUCHSIZE) >= TOUCHSIZE);
>>>
>>> p -= TOUCHSIZE; // round down to next complete TOUCHSIZE bytes
>>> memset(p,0,size);
>>> return p;
>>>}
>>>
>>>#define DEFAULT_STACK (256*1024UL)
>>>#define MIN_STACK 8192UL // 16384UL
>>>int main(int argc, char *argv[])
>>>{
>>> char * pStack = NULL;
>>> int rc;
>>>
>>> unsigned long MaxStack = DEFAULT_STACK;
>>>
>>> if (argc > 1)
>>> MaxStack=(unsigned long) atol(argv[1]);
>>> if (MaxStack < MIN_STACK)
>>> MaxStack = DEFAULT_STACK;
>>>
>>> pStack = TouchAllStack(MaxStack);
>>>
>>> return 0;
>>>}
------------------------------
From: MeekGeek <[EMAIL PROTECTED]>
Subject: Re: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 16:25:51 GMT
On 26 Sep 2000 11:03:35 -0400, Johan Kullstam
<[EMAIL PROTECTED]> wrote:
>2.95.x). they may have fixed this, but it can't hurt to check.
>just allocate a vector using a variable rather than a
>constant and gcc will magically do the right thing. do it like this
>
>int foo(
> int n)
>{
> double vec[n];
>
> *do stuff*
>
> return 0;
>}
>
>instead of
>
>int foo(
> int n)
>{
> double *vec = alloca(sizeof(double)*n);
>
> *do stuff*
>
> return 0;
>}
>
>since the former works but the latter fails.
Thanks John. I'll either find another way (like decrementing ESP
directly) or I'll be extry careful with alloca and make sure it's
working as I use it (or fix it).
M.
------------------------------
From: [EMAIL PROTECTED] (Pete Zaitcev)
Subject: Re: Linux Stack Sizes? (0/1)
Date: Tue, 26 Sep 2000 16:30:04 GMT
>[...]
> First, you are assuming that the stack lives in high memory and grows
> towards low memory. You cannot assume that. There is absolutely no
> reason the stack couldn't live in low memory, and grow upwards. Many
> implementations of UNIX and other OSs do exactly this.
"Many" meaning HP-UX, I assume. :)
This is irrelevant because we are talking Linux/i386 here.
He may have just hacked that code up in couple of minutes.
> For example, you could use alloca(). [...]
Good idea, I was just going to suggest that. Only instead, I think
it may be better for the poor soul to look how alloca() is implemented
in glibc.
--Pete
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
