On Fri, 25 Jun 1999, Greg Haerr wrote:
> On Friday, June 25, 1999 2:12 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
> : Greg Haerr writes:
> : Sounds good. Would be implemented by the compiler, or the pre-processor?
> :
> It would be implemented by the compiler, which would emit
>
On Friday, June 25, 1999 2:12 PM, Alistair Riddoch [SMTP:[EMAIL PROTECTED]] wrote:
: Greg Haerr writes:
: >
: >
: > : So form of stack check would be nice, every function call seems a little to
: > : much for a lowly 8086. How about on task switch or even interrupt (or is
: > : this too late)? I
Greg Haerr writes:
>
>
> : So form of stack check would be nice, every function call seems a little to
> : much for a lowly 8086. How about on task switch or even interrupt (or is
> : this too late)? If the chosen size for the stack is too small, it can be
> : cured by modifying the binary rathe
Greg Haerr writes:
>
>
> : > What exactly is being gained by making this modification? The stack
> : > is fixed size in both cases. Is it just that we currently pre-reserve the
>maximum
> : > combined heap/stack now, and in the future wouldn't require the heap size
> : > to be known?
> : >
: So form of stack check would be nice, every function call seems a little to
: much for a lowly 8086. How about on task switch or even interrupt (or is
: this too late)? If the chosen size for the stack is too small, it can be
: cured by modifying the binary rather than a full recompile.
:
: >
: > What exactly is being gained by making this modification? The stack
: > is fixed size in both cases. Is it just that we currently pre-reserve the maximum
: > combined heap/stack now, and in the future wouldn't require the heap size
: > to be known?
: >
:
: Thats it exactly. Currently
Chad Page writes:
>
>
> There is (was?) some stack checking done at the system call level.
> However, it's not 100% foolproof - if the program gets sp above the
> low-water mark after dipping into bss before the next system call it won't
> be detected.
>
> Now, if you had a magic #
On Fri, 25 Jun 1999, Simon Wood wrote:
> This E-Mail and any attachments hereto are strictly confidential and
> intended solely for the addressee. If you are not the intended addressee
> please notify the sender by return and delete the message. You must not
> disclose, forward or copy this E-mail
nal Message-
> From: Greg Haerr [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 24, 1999 9:19 PM
> To: 'Simon Wood'; [EMAIL PROTECTED]
> Subject: RE: ELKS: Application Code, Data, Heap and Stack Size??
>
>
> : Is there any checking on the Stack Size (
Greg Haerr writes:
>
>
> : The function stack_check() in arch/i86/kernel/process.c checks to see
> : whether the stack pointer is less then the brk pointer, and segfaults if it
> : is.
> :
> stack_check() is used by the kernel to see if the user process
> has run out of space, only during
Greg Haerr writes:
>
>
> : I am seriously considering adding this to the kernel, but I am not clear
> : why the linker needs to be tweaked. Surely the linker just deals with the
> : data and bss segments, and leaves the stack and heap to be sorted out at
> : load time?
> :
>
> Well one r
Greg Haerr writes:
>
> : The fixed size stack would probably be best placed just above the bss with
> : the heap above that. This would not require any mods to the linker or
> : binary format, just changes to the kernel.
> :
>
> What exactly is being gained by making this modification? T
On Thursday, June 24, 1999 4:24 PM, Chad Page [SMTP:[EMAIL PROTECTED]] wrote:
:
: There is (was?) some stack checking done at the system call level.
: However, it's not 100% foolproof - if the program gets sp above the
: low-water mark after dipping into bss before the next system call it
There is (was?) some stack checking done at the system call level.
However, it's not 100% foolproof - if the program gets sp above the
low-water mark after dipping into bss before the next system call it won't
be detected.
Now, if you had a magic # right after bss and checked th
> I am seriously considering adding this to the kernel, but I am not clear
> why the linker needs to be tweaked. Surely the linker just deals with the
> data and bss segments, and leaves the stack and heap to be sorted out at
> load time?
If you went data bss stack heap then yes it would work out
: The function stack_check() in arch/i86/kernel/process.c checks to see
: whether the stack pointer is less then the brk pointer, and segfaults if it
: is.
:
stack_check() is used by the kernel to see if the user process
has run out of space, only during a system call. If anyone really
: I am seriously considering adding this to the kernel, but I am not clear
: why the linker needs to be tweaked. Surely the linker just deals with the
: data and bss segments, and leaves the stack and heap to be sorted out at
: load time?
:
Well one reason would be that if the bss segme
: The fixed size stack would probably be best placed just above the bss with
: the heap above that. This would not require any mods to the linker or
: binary format, just changes to the kernel.
:
What exactly is being gained by making this modification? The stack
is fixed size in both c
On Thursday, June 24, 1999 10:44 AM, Eric J. Korpela [SMTP:[EMAIL PROTECTED]]
wrote:
:
: > We also need a stack, and maybe some heap space:-
: > Where does this go and how is it allocated?
:
: Is there process stack overflow checking in ELKS? I'm pretty sure
: I saw checking of the kernel
: Is there any checking on the Stack Size (to prevent it over writing
: the stack)?
:
Not by bcc. Let me know if you'd like me to add stack overflow checking.
: Psion (on SIBO) seem to place a fixed stack at the bottom of the data
: segment (which grows down towards DS:),
Alan Cox writes:
>
> > I know that the code sized is fixed when an application is compiled, as is
> > the initialised and un-initilised data.
> > This gives us minimum code and data segment sizes.
>
> Yes
>
> > We also need a stack, and maybe some heap space:-
> > Where does this go and how
Eric J. Korpela writes:
>
>
> > We also need a stack, and maybe some heap space:-
> > Where does this go and how is it allocated?
>
> Is there process stack overflow checking in ELKS? I'm pretty sure
> I saw checking of the kernel stack...
The function stack_check() in arch/i86/kernel/pr
> We also need a stack, and maybe some heap space:-
> Where does this go and how is it allocated?
Is there process stack overflow checking in ELKS? I'm pretty sure
I saw checking of the kernel stack...
Eric
> I know that the code sized is fixed when an application is compiled, as is
> the initialised and un-initilised data.
> This gives us minimum code and data segment sizes.
Yes
> We also need a stack, and maybe some heap space:-
> Where does this go and how is it allocated?
Linux 8086 take
Simon Wood writes:
>
> Hi,
> I'm afraid I'm not understanding this.
>
> I know that the code sized is fixed when an application is compiled, as is
> the initialised and un-initilised data.
> This gives us minimum code and data segment sizes.
>
> We also need a stack, and maybe some heap sp
25 matches
Mail list logo
