Mail Archives: djgpp-workers/2003/02/12/04:15:32

Date: Wed, 12 Feb 2003 11:12:49 +0200 (EET)
From: Esa A E Peuha <peuha AT cc DOT helsinki DOT fi>
Sender: peuha AT sirppi DOT helsinki DOT fi
To: djgpp-workers AT delorie DOT com
Subject: Re: Checking for stack overflow
In-Reply-To: <>
Message-ID: <>
References: <10302111440 DOT AA01702 AT clio DOT rice DOT edu>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Tue, 11 Feb 2003, Charles Sandmann wrote:

> I would rather call it something like __djgpp_stack_top (it may not
> be related at all to heap) if we did it.

I committed patch for __djgpp_stack_top; we should have it anyway
because __djgpp_stack_limit + _stklen won't be the real top of stack if
it's not aligned to 8-byte boundary.

> I think the change to "jb" fixes the signed-ness issue - so I'm not
> sure this is really needed.

I don't understand.  Do you mean that a single unsigned comparsion
against __djgpp_stack_limit is enough?  It's not; it's even worse than
the single signed comparsion (if esp ever wraps below zero, the unsigned
comparsion will never detect it, while the signed one will usually do).

> The new top limit will causes problems with interrupt wrappers since
> they live in heap space - fix is not to compile anything used in
> a wrapper with check stack

Yes, anything that puts esp outside the application stack certainly
shouldn't be compiled with -fstack-check.

> I'd be interested to see this working, see how much of a run-time
> impact it has, and how much checking the second limit changes the
> run-time performance.

I'll provide two version of patched gcc, one with one signed comparsion
and the other with two unsigned ones.

Esa Peuha
student of mathematics at the University of Helsinki

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019