On 10/11/20 3:08 PM, Bruno Haible wrote:
But do you have an overview which targets are meant in the doc?
Unfortunately not. I expect it'd have to be determined from the comments in GCC,
and it might also need info from various OSes and/or linkers.
Paul Eggert wrote:
> That being said, it does look like a reliability win if we start using
> -fstack-clash-protection on platforms like Fedora x86-64 that support it and
> do
> not enable it by default. Perhaps we should have a Gnulib or Autoconf macro
> that
> does that.
Yes, such a macro w
On 10/10/20 2:49 PM, Bruno Haible wrote:
gcc -fstack-clash-protection -m32 -O2 stackish.c fixes this issue.
Yes. However, the GCC manual says this about -fstack-clash-protection:
Most targets do not fully support stack clash protection. However,
on those targets '-fstack-clash-prote
Paul Eggert wrote:
> > On Linux, the kernel allows the stack to grow by any amount, if it does not
> > become closer than 1 MB to another VMA and does not violate the set limits.
> > See linux/mm/mmap.c:expand_downwards and linux/mm/mmap.c:acct_stack_growth.
> > Therefore on Linux, there is no need
On 10/10/20 5:08 AM, Bruno Haible wrote:
On Linux, the kernel allows the stack to grow by any amount, if it does not
become closer than 1 MB to another VMA and does not violate the set limits.
See linux/mm/mmap.c:expand_downwards and linux/mm/mmap.c:acct_stack_growth.
Therefore on Linux, there is
Hi Paul,
you wrote on 2020-09-22:
> I am thinking of some combination of gcc -fstack-check and/or
> -fstack-clash-protection and/or related ideas (not that I've looked into all
> the
> details). That is, I'm expecting help from the hardware, the kernel, and from
> GCC. Stack-exhaustion checkin
On 9/22/20 5:58 PM, Bruno Haible wrote:
It sounds what you want is a function that returns the stack bounds, in such a
way that every recursion step in a recursive function call the code can ask
"am I close to the stack bound? do I need to stop recursing?"
That shouldn't be necessary, except fo
