From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: Per Bothner Cc: egcs@cygnus.com Subject: Re: -fno-exceptions and libgcc.a Date: Sat, 04 Oct 1997 08:08:00 -0000 Message-id: <199710040808.IAA30892@quickstep.stanford.edu> References: <199710040010.RAA21363@kankakee.wrs.com> <199710040711.AAA25050@cygnus.com> X-SW-Source: 1997-10/msg00185.html >>>>> "Per" == Per Bothner writes: >> It is reasonable to either change the default for exception >> handling to off for C, Per> I don't understand why there is even any discussion of this. Per> The default for C *has* to -fno-exceptions, unless there is Per> *no* cost for code that does not use the exceptions. Per> Anything else is a public relations disaster in terms of the Per> perceived code quality of gcc. This *must* be fixed before Per> egcs (or gcc 2.8) is released. I suggest a different scheme: o The default remains -fno-exceptions when compiling. o At link-time, if gcc is used to link the executable, we remove the .eh_frame section. If g++/c++ is used, we keep it. I see the following benefits: o It's easy to build a library of C code that can then be linked with C++ code such that exceptions are propogated correctly. o Pure C binaries are no bigger than they used to be. Of course, we should have a switch so that the default behavior at link-time could be overridden. And, I don't know how well this would work for platforms using sjlj exceptions. Comments? Per> There should be a #pragma or __sttribute__ to specify that Per> "this code needs to be robost in the presence of exceptions." Per> This could be turned on for qsort (the canonical example of Per> possibly throwing exceptions through C code), but off for the Per> rest of the C library. Similar for libgcc. Per> --Per Bothner Cygnus Solutions bothner@cygnus.com Per> http://www.cygnus.com/~bothner -- Mark Mitchell mmitchell@usa.net Stanford University http://www.stanford.edu