Re: GNAT and -fstack-check, does it work?

[Stefan Bellon <bellon@software-erosion.org>]

On Sun, 11 Nov, Niklas Holsti wrote:

[-gnato -fstack-check]
> I have been using those options for a while, but I was recently hit 
> by a bug in which stack overflow made the program abort with 
> Segmentation Violation (signal 11 = SIGSEGV) instead of the 
> expected Storage_Error exception. This is under Debian Sarge with 
> gnat 3.15p.

We are hit by that bug, feature or whatever it is since GNAT 3.15p
onwards (up to GNAT Pro 6.0.2 now). It seems to be some combination of
options. We just decided not to specify -fstack-check. But perhaps it's
something we are missing.

BTW: We are on Debian as well (although always unstable).

> I'd appreciate to hear from the c.l.a crowd:
> 
> - Does -fstack-check work for you? Which versions of
>    GNAT, which systems? Do you need to set GNAT_STACK_LIMIT
>    too?

I see something like ...

Execution terminated by unhandled exception
Exception name: STORAGE_ERROR
Message: stack overflow (or erroneous memory access)
Call stack traceback locations:
0x43d76e99

... whenever I execute an application compiled with our switches:

  -gnat05 -gnata -gnatef -gnatf -gnatn -gnatU -gnatwa -gnatwl
  -gnatyaAbdefhiklmnprtx -O0 -g -gnato -fstack-check

> - Is the behaviour different for dynamic linking and
>    static linking? Which GNAT, which system?

We have not done static builds for a long time, but IIRC we had the
problem then as well, but don't quote me on that. GNAT versions ... see
above.

> - Have you had problems like those described in bug 13757?
>    Do you know if that bug affects GNAT?

We have never used -fstack-check with C code, I'm afraid.

-- 
Stefan Bellon