From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marc Lehmann <pcg@goof.com>
To: egcs@cygnus.com
Subject: Re: Stack variables
Date: Thu, 22 Jan 1998 02:29:00 -0000
Message-id: <19980122002142.32287@cerebro.laendle>
References: <199801172114.XAA24914@fishy.pp.sci.fi> <760.885309234@unknown>
X-SW-Source: 1998-01/msg00781.html

On Tue, Jan 20, 1998 at 08:13:54AM -0700, Jeffrey A Law wrote:
>   > I usually use Electric Fence to debug programs, but in this case it was of
>   > no use since it can't put an unmapped page before/after a stack variable.
>   > After a while I thought of a simple solution: What about having a
>   > debugging option in gcc that would allocate all stack variables with
>   > malloc()? This would slow down the program, yes, but since it would be a
>   > debugging option, it wouldn't matter.
> It's an interesting thought, but separating the stack variables from
> other uses of the stack might be rather difficult.  There's also significant
> code in the compiler which knows special things about the stack or frame
> poiner (look for stack_pointer_rtx in reload*.c and many other files).

Even more, pages are often 4k or larger in size, and each malloc (under
many memory checkers like efence) allocate at least one page.

i.e. in a normla program, instead of using, say 10k of memory, it'll use
10Mb, so I don't think this is feasible...

the bounds-checking code (like the one from gcc with bounds checking)
seems a more promising approach which catches many of these bugs
while not introducing much runtime overhead.

      -----==-                                              |
      ----==-- _                                            |
      ---==---(_)__  __ ____  __       Marc Lehmann       +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com       |e|
      -=====/_/_//_/\_,_/ /_/\_\                          --+
    The choice of a GNU generation                        |
                                                          |