http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005
--- Comment #15 from John Marino <gnugcc at marino dot st> 2011-01-05 16:25:56 UTC --- [off PR] Hi Eric, Can you clarify one statement? Regarding the ten "stack-check" tests as I can them (c5210[3x,4x,4y], cb1010[a,c,d], null_deref[1,2], stack-check[1,2]), I now understand that it is expected that these tests pass on SJLJ targets. Are these true passes meaning SJLJ targets are fully capable of handling stack overflow and segfaults? Or are these results just false positives? Thanks, John ebotcazou at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47005 > > --- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-01-05 > 15:33:24 UTC --- >> The regression tests just completed for OpenBSD i386. >> There is one failure on ACATS (cb1010a timeout)* > > This is a stack checking test. > >> 3) the STACK_CHECK_STATIC_BUILTIN macro value has no effect on OpenBSD. I >> was >> expecting failures on c5210[3x,4x,4y] and cb1010[a,b,c] but they don't fail. > > The tests should pass w and w/o it on x86, but it's better to define it. > >> 4) Despite DWARF2_UNWIND_INFO being set to 0 (meaning MD_UNWIND_SUPPORT macro >> is ignored), the null_deref and stack_check gnat.dg tests pass. in gdb, the >> segfault comes and then the program just exits normally. > > This is expected with SJLJ exceptions, you don't need MD_UNWIND_SUPPORT. > >> The summary is that the OpenBSD port is currently better then it has ever >> been, >> and one remaining ACATS failure is probably related to how OpenBSD handles >> their stack. As of today, I don't have any errors to report, but that may >> change as I discover more about the issues I just outlined above. > > Great, thanks for the detailed report. >
