Date: Wed, 12 Feb 2003 11:12:49 +0200 (EET) From: Esa A E Peuha Sender: peuha AT sirppi DOT helsinki DOT fi To: djgpp-workers AT delorie DOT com Subject: Re: Checking for stack overflow In-Reply-To: <10302111440.AA01702@clio.rice.edu> Message-ID: References: <10302111440 DOT AA01702 AT clio DOT rice DOT edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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 http://www.helsinki.fi/~peuha/