Re: PR35401 and PR30572 are gcc 4.3.0 release blockers on darwin
Jack Howarth wrote: Do we have any other targets that link gcc (and xgcc) with the shared libgcc? I see that i386 and x86_64 linux creates a gcc (and xgcc) linked to the static libgcc. If any other targets use a shared libgcc for gcc (and xgcc) they may be broken as well. That's a good hint; it certainly seems possible that this is indeed somehow related to the problem. However, I don't know the answer to your question. Because of the convoluted way in which the GCC build process works (in particular, that binaries are run out of the $objdir, which has a different layout than the eventual installation), making the driver depend on shared libraries created during the build is certainly going to be tricky. In particular, on most platforms LD_LIBRARY_PATH (or equivalent) will have to be set just so whenever xgcc is run. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: [PATCH][4.3] Deprecate -ftrapv
Joseph S. Myers wrote:
int f(int a, int b) { return 0 * (a + b); }
They are the natural interpretation of -ftrapv that's simplest to describe
in terms of the abstract machine of the C standard: any signed integer
arithmetic overflow in the abstract machine (and maybe integer division by
0, signed or unsigned) should be guaranteed to yield a trap at runtime.
I agree with everything you've written, including, in particular, that
making this explicit in the IL (via special tree codes for, e.g.,
trapping-add) would be best.
However, I don't think doing all of that work is required to make this
feature useful to people. You seem to be focusing on making -ftrapv
capture 100% of overflows, so that people could depend on their programs
crashing if they had an overflow. That might be useful in two
circumstances: (a) getting bugs out (though for an example like the one
above, I can well imagine many people not considering that a bug worth
fixing), and (b) in safety-critical situations where it's better to die
than do the wrong thing.
But, I think that (a) has been the most common use of -ftrapv, and for
bug-detection, it's not vital that we get 100% of the overflows.
Detecting some/most bugs is a lot better than nothing!
If you set the bar for the feature too high, we may end up not having
-ftrapv at all -- because nobody gets around to implementing it --
rather than having an -ftrapv that catches some, but not all overflow
errors. And that seems unfortunate.
I think there's a staged implementation plan here that delivers value
early, but still allows us to gradually progress towards the ideal state
over time. In particular:
1. Move the checks from expand to GIMPLE, turning them into explicit
checks in the IL, or into calls to library functions (but not necessary
libcalls per se). This might be more expensive at run-time than the old
implementation, but no worse than what the Ada front-end is already doing.
2. Introduce new tree codes and change the GIMPLE code to only insert
the checks for operations using those codes -- but after gimplification
these tree codes are no longer used.
3. Plumb the new operations through the TREE-SSA optimizers, add support
for generating the checks during expand for those trapping operations
that make it to that point, and disable the insertion of checking at
GIMPLE-time.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Re: [PATCH][4.3] Deprecate -ftrapv
On Sun, 2 Mar 2008, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>
> > > > int f(int a, int b) { return 0 * (a + b); }
>
> > They are the natural interpretation of -ftrapv that's simplest to describe
> > in terms of the abstract machine of the C standard: any signed integer
> > arithmetic overflow in the abstract machine (and maybe integer division by
> > 0, signed or unsigned) should be guaranteed to yield a trap at runtime.
>
> I agree with everything you've written, including, in particular, that making
> this explicit in the IL (via special tree codes for, e.g., trapping-add) would
> be best.
>
> However, I don't think doing all of that work is required to make this feature
> useful to people. You seem to be focusing on making -ftrapv capture 100% of
> overflows, so that people could depend on their programs crashing if they had
> an overflow. That might be useful in two circumstances: (a) getting bugs out
> (though for an example like the one above, I can well imagine many people not
> considering that a bug worth fixing), and (b) in safety-critical situations
> where it's better to die than do the wrong thing.
>
> But, I think that (a) has been the most common use of -ftrapv, and for
> bug-detection, it's not vital that we get 100% of the overflows. Detecting
> some/most bugs is a lot better than nothing!
>
> If you set the bar for the feature too high, we may end up not having -ftrapv
> at all -- because nobody gets around to implementing it -- rather than having
> an -ftrapv that catches some, but not all overflow errors. And that seems
> unfortunate.
>
> I think there's a staged implementation plan here that delivers value early,
> but still allows us to gradually progress towards the ideal state over time.
> In particular:
>
> 1. Move the checks from expand to GIMPLE, turning them into explicit checks in
> the IL, or into calls to library functions (but not necessary libcalls per
> se). This might be more expensive at run-time than the old implementation,
> but no worse than what the Ada front-end is already doing.
>
> 2. Introduce new tree codes and change the GIMPLE code to only insert the
> checks for operations using those codes -- but after gimplification these tree
> codes are no longer used.
>
> 3. Plumb the new operations through the TREE-SSA optimizers, add support for
> generating the checks during expand for those trapping operations that make it
> to that point, and disable the insertion of checking at GIMPLE-time.
Nice plan. Though I doubt that even this simple one will be carried out,
as even the simple bugs in the current implementation stay around for at
least 5 years.
Even I think that there are more useful things to spend time on than
making -ftrapv work. Especially fixing its counter-part, -fwrapv, thus
the encoding of integer overflow in our IL, should be tackled with
higher priority. With the same solutions basically - add variants of
the tree codes to note "may overflow".
I believe at last years summit Ian told me that someone at google was
working on this -- Ian is this still true?
Thanks,
Richard.
Re: [PATCH][4.3] Deprecate -ftrapv
Mark Mitchell wrote: However, I don't think doing all of that work is required to make this feature useful to people. You seem to be focusing on making -ftrapv capture 100% of overflows, so that people could depend on their programs crashing if they had an overflow. That might be useful in two circumstances: (a) getting bugs out (though for an example like the one above, I can well imagine many people not considering that a bug worth fixing), and (b) in safety-critical situations where it's better to die than do the wrong thing. I don't agree with this list, first it misses (c) be useful for Ada conformance, where 100% of cases must be caught Second, generally speaking in safety-critical systems, you don't want overflow checking, because a) it would generate deactivated code intefering with certification b) in sc code, you have to make sure a priori that there are no overflows (see http://www.praxis-cs.com/pdfs/Industrial_strength.pdf for one approach). c) exceptions can be safety hazards if you don't carefully consider what to do with them (think about Ariane 5). So for me, the two uses of -ftrapv are debugging in languages like C and Fortran, and for debugging and language conformance in languages like Ada. Certainly for the debugging use, a solution that is not 100% is still useful.
Re: [PATCH][4.3] Deprecate -ftrapv
> I agree with everything you've written, including, in particular, that > making this explicit in the IL (via special tree codes for, e.g., > trapping-add) would be best. I'd be in favor of flags rather than new codes. For the most part, all processing of non-trapping operations and trapping operations are the same and we already have predicates for when operations trap that we can use to tell the difference. I think that flag aproach would be far less work because adding new operations to all the various switch statements is a lot of work. > However, I don't think doing all of that work is required to make this > feature useful to people. You seem to be focusing on making -ftrapv > capture 100% of overflows, so that people could depend on their programs > crashing if they had an overflow. That might be useful in two > circumstances: (a) getting bugs out (though for an example like the one > above, I can well imagine many people not considering that a bug worth > fixing), and (b) in safety-critical situations where it's better to die > than do the wrong thing. You forgot the third: if Ada is to use it rather than its own approach, it must indeed be 100% reliable. Robert is correct that if it's sufficiently more efficient than Ada's approach, it can be made the default, so that by default range-checking is on in Ada, but not in a 100% reliable fashion. This means there's be three states: explicitly enabled, using Ada's mechanism, suppressed, using neither, or the default, using GCC's. But if GCC's mechanism also did things like called functions that did special arithmetic, there'd be no point in Ada using this.
Re: [PATCH][4.3] Deprecate -ftrapv
Richard Guenther wrote: Nice plan. Though I doubt that even this simple one will be carried out, as even the simple bugs in the current implementation stay around for at least 5 years. Well let's see .. we (AdaCore) will try to focus more attention on this to evaluate whether it is feasible to get this feature working well enough to use in GNAT.
Re: [PATCH][4.3] Deprecate -ftrapv
On Sun, Mar 2, 2008 at 2:00 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Sat, 1 Mar 2008, Richard Guenther wrote:
>
> > I missed once point noticed by Joseph also, that the libgcc implementation
> > uses signed types in the implementation of the trapping arithmetics.
> > Where we of course optimize away the overflow check, so the libgcc
> > routines will never trap. (if it does work in some cases then this
> > would be a missed optimization, so sooner or later it is going to
> > break more)
>
> This is of course trivial to fix. OK to commit the following patch?
> Bootstrapped with no regressions on i686-pc-linux-gnu.
Ok.
Thanks,
Richard.
> 2008-03-02 Joseph Myers <[EMAIL PROTECTED]>
>
> * libgcc2.c (__addvSI3, __addvsi3, __addvDI3, __subvSI3,
> __subvsi3, __subvDI3, __negvSI2, __negvsi2, __negvDI2, __absvSI2,
> __absvsi2, __absvDI2): Use unsigned arithmetic.
>
> Index: libgcc2.c
> ===
> --- libgcc2.c (revision 132803)
> +++ libgcc2.c (working copy)
> @@ -84,7 +84,7 @@
> Wtype
> __addvSI3 (Wtype a, Wtype b)
> {
> - const Wtype w = a + b;
> + const Wtype w = (UWtype) a + (UWtype) b;
>
>if (b >= 0 ? w < a : w > a)
> abort ();
> @@ -95,7 +95,7 @@
> SItype
> __addvsi3 (SItype a, SItype b)
> {
> - const SItype w = a + b;
> + const SItype w = (USItype) a + (USItype) b;
>
>if (b >= 0 ? w < a : w > a)
> abort ();
> @@ -109,7 +109,7 @@
> DWtype
> __addvDI3 (DWtype a, DWtype b)
> {
> - const DWtype w = a + b;
> + const DWtype w = (UDWtype) a + (UDWtype) b;
>
>if (b >= 0 ? w < a : w > a)
> abort ();
> @@ -122,7 +122,7 @@
> Wtype
> __subvSI3 (Wtype a, Wtype b)
> {
> - const Wtype w = a - b;
> + const Wtype w = (UWtype) a - (UWtype) b;
>
>if (b >= 0 ? w > a : w < a)
> abort ();
> @@ -133,7 +133,7 @@
> SItype
> __subvsi3 (SItype a, SItype b)
> {
> - const SItype w = a - b;
> + const SItype w = (USItype) a - (USItype) b;
>
>if (b >= 0 ? w > a : w < a)
> abort ();
> @@ -147,7 +147,7 @@
> DWtype
> __subvDI3 (DWtype a, DWtype b)
> {
> - const DWtype w = a - b;
> + const DWtype w = (UDWtype) a - (UDWtype) b;
>
>if (b >= 0 ? w > a : w < a)
> abort ();
> @@ -187,7 +187,7 @@
> Wtype
> __negvSI2 (Wtype a)
> {
> - const Wtype w = -a;
> + const Wtype w = -(UWtype) a;
>
>if (a >= 0 ? w > 0 : w < 0)
> abort ();
> @@ -198,7 +198,7 @@
> SItype
> __negvsi2 (SItype a)
> {
> - const SItype w = -a;
> + const SItype w = -(USItype) a;
>
>if (a >= 0 ? w > 0 : w < 0)
> abort ();
> @@ -212,7 +212,7 @@
> DWtype
> __negvDI2 (DWtype a)
> {
> - const DWtype w = -a;
> + const DWtype w = -(UDWtype) a;
>
>if (a >= 0 ? w > 0 : w < 0)
> abort ();
> @@ -231,7 +231,7 @@
> #ifdef L_negvsi2
> w = __negvSI2 (a);
> #else
> -w = -a;
> +w = -(UWtype) a;
>
>if (w < 0)
> abort ();
> @@ -249,7 +249,7 @@
> #ifdef L_negvsi2
> w = __negvsi2 (a);
> #else
> -w = -a;
> +w = -(USItype) a;
>
>if (w < 0)
> abort ();
> @@ -270,7 +270,7 @@
> #ifdef L_negvdi2
> w = __negvDI2 (a);
> #else
> -w = -a;
> +w = -(UDWtype) a;
>
>if (w < 0)
> abort ();
>
>
>
> --
> Joseph S. Myers
> [EMAIL PROTECTED]
>
Re: [PATCH][4.3] Deprecate -ftrapv
On Sat, 1 Mar 2008, Richard Guenther wrote:
> I missed once point noticed by Joseph also, that the libgcc implementation
> uses signed types in the implementation of the trapping arithmetics.
> Where we of course optimize away the overflow check, so the libgcc
> routines will never trap. (if it does work in some cases then this
> would be a missed optimization, so sooner or later it is going to
> break more)
This is of course trivial to fix. OK to commit the following patch?
Bootstrapped with no regressions on i686-pc-linux-gnu.
2008-03-02 Joseph Myers <[EMAIL PROTECTED]>
* libgcc2.c (__addvSI3, __addvsi3, __addvDI3, __subvSI3,
__subvsi3, __subvDI3, __negvSI2, __negvsi2, __negvDI2, __absvSI2,
__absvsi2, __absvDI2): Use unsigned arithmetic.
Index: libgcc2.c
===
--- libgcc2.c (revision 132803)
+++ libgcc2.c (working copy)
@@ -84,7 +84,7 @@
Wtype
__addvSI3 (Wtype a, Wtype b)
{
- const Wtype w = a + b;
+ const Wtype w = (UWtype) a + (UWtype) b;
if (b >= 0 ? w < a : w > a)
abort ();
@@ -95,7 +95,7 @@
SItype
__addvsi3 (SItype a, SItype b)
{
- const SItype w = a + b;
+ const SItype w = (USItype) a + (USItype) b;
if (b >= 0 ? w < a : w > a)
abort ();
@@ -109,7 +109,7 @@
DWtype
__addvDI3 (DWtype a, DWtype b)
{
- const DWtype w = a + b;
+ const DWtype w = (UDWtype) a + (UDWtype) b;
if (b >= 0 ? w < a : w > a)
abort ();
@@ -122,7 +122,7 @@
Wtype
__subvSI3 (Wtype a, Wtype b)
{
- const Wtype w = a - b;
+ const Wtype w = (UWtype) a - (UWtype) b;
if (b >= 0 ? w > a : w < a)
abort ();
@@ -133,7 +133,7 @@
SItype
__subvsi3 (SItype a, SItype b)
{
- const SItype w = a - b;
+ const SItype w = (USItype) a - (USItype) b;
if (b >= 0 ? w > a : w < a)
abort ();
@@ -147,7 +147,7 @@
DWtype
__subvDI3 (DWtype a, DWtype b)
{
- const DWtype w = a - b;
+ const DWtype w = (UDWtype) a - (UDWtype) b;
if (b >= 0 ? w > a : w < a)
abort ();
@@ -187,7 +187,7 @@
Wtype
__negvSI2 (Wtype a)
{
- const Wtype w = -a;
+ const Wtype w = -(UWtype) a;
if (a >= 0 ? w > 0 : w < 0)
abort ();
@@ -198,7 +198,7 @@
SItype
__negvsi2 (SItype a)
{
- const SItype w = -a;
+ const SItype w = -(USItype) a;
if (a >= 0 ? w > 0 : w < 0)
abort ();
@@ -212,7 +212,7 @@
DWtype
__negvDI2 (DWtype a)
{
- const DWtype w = -a;
+ const DWtype w = -(UDWtype) a;
if (a >= 0 ? w > 0 : w < 0)
abort ();
@@ -231,7 +231,7 @@
#ifdef L_negvsi2
w = __negvSI2 (a);
#else
-w = -a;
+w = -(UWtype) a;
if (w < 0)
abort ();
@@ -249,7 +249,7 @@
#ifdef L_negvsi2
w = __negvsi2 (a);
#else
-w = -a;
+w = -(USItype) a;
if (w < 0)
abort ();
@@ -270,7 +270,7 @@
#ifdef L_negvdi2
w = __negvDI2 (a);
#else
-w = -a;
+w = -(UDWtype) a;
if (w < 0)
abort ();
--
Joseph S. Myers
[EMAIL PROTECTED]
Re: [PATCH][4.3] Deprecate -ftrapv
Frank Ch. Eigler wrote: Mark Mitchell <[EMAIL PROTECTED]> writes: [...] You seem to be focusing on making -ftrapv capture 100% of overflows, so that people could depend on their programs crashing if they had an overflow. That might be useful in two circumstances: (a) getting bugs out (though for an example like the one above, I can well imagine many people not considering that a bug worth fixing), and (b) in safety-critical situations where it's better to die than do the wrong thing. Are you including in "safety-critical" all the security-related software, where signed-overflow is a popular exploit? If so, you are undervaluing the "better to die than do the wrong thing" principle. (This has come up several times here in the past, but not recently AFAICT.) Safety-critical and security-critical software are two totally different concepts. Be careful not to confuse them. In safety-critical software, e.g. avionics system, it is not acceptable for the system to crash. In this context, the metaphorical "better to die", becomes all too real! For security-critical software that is not safety-critical, e.g. a banking terminal, it is indeed better to crash than to compromise security. However, in practice, it is hard to imagine a security-critical piece of software that would not take equal care to avoid any possibility of exceptional conditions at run time. For general security issues, especially with type unsafe languages, anything you can do at run-time to increase type safety certainly helps. However, I would suspect that -ftrapv is likely to be viewed and used only as a debugging aid in C, rather than something you routinely deploy in delivered software to improve security. - FChE
Re: [PATCH][4.3] Deprecate -ftrapv
Mark Mitchell <[EMAIL PROTECTED]> writes: > [...] You seem to be focusing on making -ftrapv capture 100% of > overflows, so that people could depend on their programs crashing if > they had an overflow. That might be useful in two circumstances: > (a) getting bugs out (though for an example like the one above, I > can well imagine many people not considering that a bug worth > fixing), and (b) in safety-critical situations where it's better to > die than do the wrong thing. Are you including in "safety-critical" all the security-related software, where signed-overflow is a popular exploit? If so, you are undervaluing the "better to die than do the wrong thing" principle. (This has come up several times here in the past, but not recently AFAICT.) - FChE
Re: [PATCH][4.3] Deprecate -ftrapv
Hi - On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote: > [...] Safety-critical and security-critical software are two > totally different concepts. Be careful not to confuse them. In > safety-critical software, e.g. avionics system, it is not acceptable > for the system to crash. In this context, the metaphorical "better > to die", becomes all too real! (Off topic, but I'd expect that avionics software is engineered with enough layers of protection, including catching traps, so that a -ftrapv hit would not cause a deep impact.) > [...] However, in practice, it is hard to imagine a > security-critical piece of software that would not take equal care > to avoid any possibility of exceptional conditions at run time. Maybe, but we just don't live in that world. > For general security issues, especially with type unsafe languages, > anything you can do at run-time to increase type safety certainly > helps. Right, but gcc's approach is unsympathetic. With -fstrict-overflow becoming default in the usual "-O2 -g" builds, latent signed-overflow bugs might become even harder to find. It's as if GCC is sending the a message like "Security is your problem - we favour 100% Pure C Code.". > However, I would suspect that -ftrapv is likely to be viewed and > used only as a debugging aid in C, rather than something you > routinely deploy in delivered software to improve security. I guess it depends on how robust (=> predictable to experts) the mechanism becomes. The glibc fortify widget (enabled by some robust gcc extensions) has found lots of use. - FChE
Re: [PATCH][4.3] Deprecate -ftrapv
Frank Ch. Eigler wrote: Hi - On Sun, Mar 02, 2008 at 09:30:25AM -0500, Robert Dewar wrote: [...] Safety-critical and security-critical software are two totally different concepts. Be careful not to confuse them. In safety-critical software, e.g. avionics system, it is not acceptable for the system to crash. In this context, the metaphorical "better to die", becomes all too real! (Off topic, but I'd expect that avionics software is engineered with enough layers of protection, including catching traps, so that a -ftrapv hit would not cause a deep impact.) As I say, it is more usual in avionics software to rely on proving or demonstrating during the certification process that the code is correct. DER's do not look too kindly on code that says "if something is wrong do bla", they want to be convinced that nothing can go wrong. And don't be sure about impact, as I mentioned the Ariane-5 disaster was caused by a run time exception not handled properly, the rocket would have been fine if there had been no overflow test in place. Non-critical wrong answers are better than having to blow up the rocket some times :-) [...] However, in practice, it is hard to imagine a security-critical piece of software that would not take equal care to avoid any possibility of exceptional conditions at run time. Maybe, but we just don't live in that world. I am not sure who "we" is here, those of us who live in the DO-178B and MILS worlds definitely do take that kind of care. However, I would suspect that -ftrapv is likely to be viewed and used only as a debugging aid in C, rather than something you routinely deploy in delivered software to improve security. I guess it depends on how robust (=> predictable to experts) the mechanism becomes. The glibc fortify widget (enabled by some robust gcc extensions) has found lots of use. Again, the issue is whether such things are for finding bugs during development, or defending against bugs that make it through the entire development process. Even in the Ada world, it is normal to turn off exceptions in safety-critical code for the final delivered software that runs on planes. - FChE
Re: [PATCH][4.3] Deprecate -ftrapv
Hi - On Sun, Mar 02, 2008 at 10:20:30AM -0500, Robert Dewar wrote: > [...] > >(Off topic, but I'd expect that avionics software is engineered with > >enough layers of protection, including catching traps, so that a > >-ftrapv hit would not cause a deep impact.) > > As I say, it is more usual in avionics software to rely on proving > or demonstrating during the certification process that the code > is correct. [... and exception trapping is sometimes disabled on > deployed code ...] Wow. This gives one the impression of eschewing of defense in depth, but I suppose the overall record (positive and negative) speaks for itself. > >>[...] However, in practice, it is hard to imagine a > >>security-critical piece of software that would not take equal care > >>to avoid any possibility of exceptional conditions at run time. > > > >Maybe, but we just don't live in that world. > > I am not sure who "we" is here, those of us who live in the > DO-178B and MILS worlds definitely do take that kind of care. If you're saying that security-related software written by people working in DO-178B workflows tends to be as well cared-for as saftery-related software, OK. But most security-related software we normal folks use is not written by such people / processes. > [...] Again, the issue is whether such things are for finding bugs > during development, or defending against bugs that make it through > the entire development process. Those decisions may be made by separate people or even organizations. An OS distributor can decide to use different compiler flags than the code author - whether that be for extra trustworthiness, speed, portability, compatibility. Ideally, protective measures should be usable for either subject. > Even in the Ada world, it is normal to turn off exceptions in > safety-critical code for the final delivered software that runs on > planes. (Drifting farther off topic onto my personal curiosity: are exception handling paths just not considered powerful & robust enough to design in and rely on? Do these machines have e.g. watchdog timers? Run -O2 vs. -O0 code?) - FChE
Re: [PATCH][4.3] Deprecate -ftrapv
(Off topic, but I'd expect that avionics software is engineered with enough layers of protection, including catching traps, so that a -ftrapv hit would not cause a deep impact.) Actually this discussion is not *so* off-topic. if you regard -ftrapv as something that would be enabled in critical code in the final production build, you have a much different view, than if it is a debugging aid, which can help to find bugs, but makes no guarantees.
Re: [PATCH][4.3] Deprecate -ftrapv
Frank Ch. Eigler wrote: Hi - On Sun, Mar 02, 2008 at 10:20:30AM -0500, Robert Dewar wrote: [...] (Off topic, but I'd expect that avionics software is engineered with enough layers of protection, including catching traps, so that a -ftrapv hit would not cause a deep impact.) As I say, it is more usual in avionics software to rely on proving or demonstrating during the certification process that the code is correct. [... and exception trapping is sometimes disabled on deployed code ...] Wow. This gives one the impression of eschewing of defense in depth, but I suppose the overall record (positive and negative) speaks for itself. That's right, defense in depth is a concept that comes from dealing with code that you assume might fail. Safety-critical avionics code is code that you assume will never fail. There has been at least one incident of a software bug in certified code, but it is very rare, and the record is impressive (no life has been lost because of a software bug in the history of commercial aviation). And that's using an informal standard (DO-178B) and we think we can do much better than this (e.g. in the MILS contexts, where higher EAL levels require formal verification techniques to be used, DO-178B has no such requirement). If you're saying that security-related software written by people working in DO-178B workflows tends to be as well cared-for as saftery-related software, OK. But most security-related software we normal folks use is not written by such people / processes. Right, and security-related (a nice term, which distinguishes itself from security-critical) software can certainly benefit from defense in depth. Even formally proved security-critical software can benefit, because corrupting code or data by physical intrusion may still be limited in effect because of such defenses [...] Again, the issue is whether such things are for finding bugs during development, or defending against bugs that make it through the entire development process. Those decisions may be made by separate people or even organizations. An OS distributor can decide to use different compiler flags than the code author - whether that be for extra trustworthiness, speed, portability, compatibility. Ideally, protective measures should be usable for either subject. Yes indeed ... Even in the Ada world, it is normal to turn off exceptions in safety-critical code for the final delivered software that runs on planes. (Drifting farther off topic onto my personal curiosity: are exception handling paths just not considered powerful & robust enough to design in and rely on? Do these machines have e.g. watchdog timers? Run -O2 vs. -O0 code?) Usually you avoid -O2 in these contexts, too hard to establish the required source-to-object traceability. We most typially use -O1 with a couple of optimizations suppressed (e.g. if-conversion). It is not that exception handling paths are not powerful or robust. It is that a) they should not be needed if the code is correct b) they create a testing hazard, you can't have untested code in an SC system, so you have to test the exception case, which is tricky if in fact it is not possible for the exception to occur. So you have to prove in any casea that the exception can't occur to justify not testing it, and if you can convince the certification authorities that testing is not required, you have convinced them that the exception cannot happen, so why leave in the code. There are those who prefer to leave checks on in safety-critical delivered code, the argument rages strongly on both sides :-)
Re: [PATCH][4.3] Deprecate -ftrapv
> There has been at least one incident of a software bug in certified > code, but it is very rare, and the record is impressive (no life > has been lost because of a software bug in the history of commercial > aviation). I agree with all you've said so far, but this statement above is a bit too optimistic, unfortunately :-( Air France flight 296 in 1988 is one example. It killed 3 people. The cause was a systems bug that kept engines in idle in a low altitude fly-by at a French air show. The systems assumed the pilot was trying to land... Malaysia Airlines Flight 124 is an example of a near-miss. And the recent crash of British Airways Flight 38 also probably was due to a software bug (investigation ongoing, of course). In military aviation, there are plenty examples of software bugs that killed people (V-22, Gripen, the F-22 equator bug, etc...). I would guess all of these were flying with certified software. Gr. Steven
Re: Possible GCC 4.3 driver regression caused by your patch
Greg Schafer wrote: Hi Carlos and Mark, Your "Relocated compiler should not look in $prefix" patch here: http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html appears to have caused a regression in my GCC 4.3 testing. In summary, there is a small window *during the GCC build itself* where GCC does not pick up the correct startfiles. For example, when GCC_FOR_TARGET is called to build the target libraries, the startfiles in $prefix/lib are not used. Instead, the startfiles from the host's /usr/lib are used which breaks my build. Note that the problem seems to rectify itself once the just-built GCC is installed into $prefix. Here's the scenario: - Native build - i686-pc-linux-gnu - --prefix=/temptools - Glibc already installed in /temptools/lib What options did you use to configure the compiler? Could you double check your host system is actually i686-pc-linux-gnu? When you say "breaks my build", what error are you seeing? Cheers, Carlos. -- Carlos O'Donell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x716
Re: [PATCH][4.3] Deprecate -ftrapv
Steven Bosscher wrote: There has been at least one incident of a software bug in certified code, but it is very rare, and the record is impressive (no life has been lost because of a software bug in the history of commercial aviation). I agree with all you've said so far, but this statement above is a bit too optimistic, unfortunately :-( Air France flight 296 in 1988 is one example. It killed 3 people. The cause was a systems bug that kept engines in idle in a low altitude fly-by at a French air show. The systems assumed the pilot was trying to land... That's often cited, but it was not a software bug, the software met the specifications perfectly, a reasonably complete account is in http://en.wikipedia.org/wiki/Air_France_Flight_296. Note that the captain was found guilty of manslaughter, so this is rather far from being a software problem. Yes, maybe with a different spec, the software could have helped rescue the situation, but to say this crashed because of a bug is mistaken. The above cited entry, dealing with several causes, does not even mention software. It appears likely the flight recorder was tampered with or replaced, and the barometric indicator may have failed. This was not a normal commercial flight, it was a pilot playing dangerous games at an airshow on a chartered flight. For much more information and many references, see http://www.experiencefestival.com/air_france_flight_296_-_investigation_irregularities Malaysia Airlines Flight 124 is an example of a near-miss. Yes, that is the one I referred to, right now it is *the* example. For official report, see http://www.atsb.gov.au/publications/investigation_reports/2005/AAIR/pdf/aair200503722_001.pdf the issue was proper software handling of an unusual dual hardware failure. A definite bug. And the recent crash of British Airways Flight 38 also probably was due to a software bug (investigation ongoing, of course). This is not at all the conclusion of the preliminary investigation. We know it was due to fuel flow limitations, but so far have no idea why, and there is so far no hint that this was a software problem. I have a paper copy of the AAIB preliminary report, but as far as I can tell, this is not posted online, though you can find excerpts at http://propilotnews.com/2008/01/uks-aaib-initial-report-on-british.html. In military aviation, there are plenty examples of software bugs that killed people (V-22, Gripen, the F-22 equator bug, etc...). I would guess all of these were flying with certified software. You probably guess wrong, it has only recently become standard to certify military planes. The only reason it is done is because they fly through civilian space. Military applications are not considered safety-critical .. the main purpose of weapons is to kill people, not to preserve life at all costs! As for your list, you would have to be more detailed in your citations. I am not sure what you mean by the equator bug, if you are referring to the dateline bug, yes, that was a bug in certified software. I know of no "equator bug", perhaps urban legend at work? I don't know of any official account of the dateline bug yet. For confirmation of my basic claim that no commercial aircraft deaths have been caused by software, see for example http://online.wsj.com/article/SB114895279859065931-search.html?KEYWORDS=flight+check&COLLECTION=wsjie/6month "Serious software bugs such as those aboard Malaysia Airlines Flight 124 haven't been blamed for any major commercial jet crash" ...
Re: [PATCH][4.3] Deprecate -ftrapv
Ross Ridge wrote: Actually, that's a different issue than catching 100% of overflows, which apparently Ada doesn't require. Well basically Ada does require catching all overflows, the only issue is the optimization issue that we already discussed, it would be acceptable to not catch this. However, if we write: X := Y + Z; then Ada demands we catch overflow with 100% reliability, so it really depends on whether we can accurately characterize the cases in which -ftrapv "fails". Note that for static expressions: X : Integer := 9817236498761928736498712334 * 123412334 / 918273649876123938474698172364; The Ada standard requires computation in infinite precision, it would be wrong to catch intermediate overflow, but the Ada front end takes care of all that. Robert is correct that if it's sufficiently more efficient than Ada's approach, it can be made the default, so that by default range-checking is on in Ada, but not in a 100% reliable fashion. On the issue of performance, out of curiosity I tried playing around with the IA-32 INTO instruction. I noticed two things, the first was that instruction wasn't supported in 64-bit mode, and the second was that it on the Linux I was using, it generated SIGSEGV signal that was indistinguishable from any other SIGSEGV. If Ada needs to be able to catch and distinguish overflow exceptions, this and possibile other cases of missing operating support might make processor specific overlow support detrimental. Usually there are ways of telling what is going on at a sufficiently low level, but in any case, code using the conditional jump instruction (jo/jno) is hugely better than what we do now (and it is often faster to usea jo than into). Ross Ridge
Re: [PATCH][4.3] Deprecate -ftrapv
Mark Mitchell writes: > However, I don't think doing all of that work is required to make this > feature useful to people. You seem to be focusing on making -ftrapv > capture 100% of overflows, so that people could depend on their programs > crashing if they had an overflow. That might be useful in two > circumstances: (a) getting bugs out (though for an example like the one > above, I can well imagine many people not considering that a bug worth > fixing), and (b) in safety-critical situations where it's better to die > than do the wrong thing. Richard Kenner writed: > You forgot the third: if Ada is to use it rather than its own approach, > it must indeed be 100% reliable. Actually, that's a different issue than catching 100% of overflows, which apparently Ada doesn't require. > Robert is correct that if it's sufficiently more efficient than Ada's > approach, it can be made the default, so that by default range-checking > is on in Ada, but not in a 100% reliable fashion. On the issue of performance, out of curiosity I tried playing around with the IA-32 INTO instruction. I noticed two things, the first was that instruction wasn't supported in 64-bit mode, and the second was that it on the Linux I was using, it generated SIGSEGV signal that was indistinguishable from any other SIGSEGV. If Ada needs to be able to catch and distinguish overflow exceptions, this and possibile other cases of missing operating support might make processor specific overlow support detrimental. Ross Ridge
Re: [PATCH][4.3] Deprecate -ftrapv
Ross Ridge wrote: Robert Dewar write: Usually there are ways of telling what is going on at a sufficiently low level, but in any case, code using the conditional jump instruction (jo/jno) is hugely better than what we do now (and it is often faster to usea jo than into). My point is that using INTO or some other processor's overlow mechanism that requires operating system support wouldn't necessarily be better for Ada, even it performs better (or uses less space) than the alternatives. Having the program crash with a vague exception would meet the requirements of -ftrapv, but not Ada. But, once again, using the processor specific JO instruction will be much better for Ada than double length arithmetic, using JO does not involve a "program crash with a vague exception". Similarly, testing the sticky overflow flag on Power is also quite reasonable. Ross Ridge
[RFC] GCC caret diagnostics
Dear all,
Here is a patch that give us caret diagnostics in C/C++. There a lot
of things that can be improved but because I wanted to get some
feedback with my current approach.
Basically, I store a pointer linebuf in the line_map structure to a
character in the input file buffer. The character corresponds to the
first character in the line corresponding to TO_LINE in the line_map
structure. The downside of this is that the buffer cannot be freed
anymore. I am not sure whether this is better than storing a duplicate
of the line as gfortran does. The third approach would be to store an
offset and when generating diagnostics, reopen the file, fseek to the
offset and print that line.
One line_map can contain information about several lines, so we still
need to find the correct position for a line within linebuf. That is
what the hack in expand_location is for. It would be nice to have a
way to point directly to the beginning of each line: multiple pointers
per line_map?
Well, comments, ideas, code, questions, help are all welcome.
Cheers,
Manuel.
Index: gcc/tree.c
===
--- gcc/tree.c (revision 132680)
+++ gcc/tree.c (working copy)
@@ -3479,17 +3479,32 @@ expand_location (source_location loc)
if (loc == 0)
{
xloc.file = NULL;
xloc.line = 0;
xloc.column = 0;
+ xloc.linebuf = NULL;
}
else
{
const struct line_map *map = linemap_lookup (line_table, loc);
+ int i;
xloc.file = map->to_file;
xloc.line = SOURCE_LINE (map, loc);
xloc.column = SOURCE_COLUMN (map, loc);
+ xloc.linebuf = SOURCE_LINEBUFFER (map);
+ if (xloc.linebuf != NULL)
+ {
+ i = xloc.line - map->to_line;
+ for (;;)
+ {
+ if (i == 0 || *xloc.linebuf == '\0')
+ break;
+ if (*xloc.linebuf == '\n')
+ i--;
+ xloc.linebuf++;
+ }
+ }
};
return xloc;
}
Index: gcc/diagnostic.c
===
--- gcc/diagnostic.c(revision 132680)
+++ gcc/diagnostic.c(working copy)
@@ -160,10 +160,47 @@ diagnostic_build_prefix (diagnostic_info
: flag_show_column && s.column != 0
? build_message_string ("%s:%d:%d: %s", s.file, s.line, s.column, text)
: build_message_string ("%s:%d: %s", s.file, s.line, text));
}
+
+#define DIAGNOSTICS_CARET_CHAR '^'
+static const unsigned char *
+get_source_line (expanded_location s)
+{
+ return s.linebuf;
+}
+static void
+diagnostic_show_locus (diagnostic_context * context ATTRIBUTE_UNUSED,
+ diagnostic_info *diagnostic)
+{
+ const unsigned char *line;
+ int max_width = 80;
+ expanded_location s;
+
+ if (!context->show_caret)
+return;
+
+ s = expand_location (diagnostic->location);
+ line = get_source_line (s);
+ if (line == NULL)
+return;
+
+ putchar (' ');
+
+ while (max_width > 0 && *line != '\0' && *line != '\n')
+{
+ max_width--;
+ putchar (*line);
+ line++;
+}
+ putchar('\n');
+ gcc_assert (s.column > 0);
+ printf (" %*c\n", s.column, DIAGNOSTICS_CARET_CHAR);
+}
+
+
/* Count a diagnostic. Return true if the message should be printed. */
static bool
diagnostic_count_diagnostic (diagnostic_context *context,
diagnostic_info *diagnostic)
{
@@ -418,10 +455,11 @@ diagnostic_report_diagnostic (diagnostic
pp_format (context->printer, &diagnostic->message);
(*diagnostic_starter (context)) (context, diagnostic);
pp_output_formatted_text (context->printer);
(*diagnostic_finalizer (context)) (context, diagnostic);
pp_flush (context->printer);
+ diagnostic_show_locus (context, diagnostic);
diagnostic_action_after_output (context, diagnostic);
diagnostic->message.format_spec = saved_format_spec;
diagnostic->abstract_origin = NULL;
}
Index: gcc/diagnostic.h
===
--- gcc/diagnostic.h(revision 132680)
+++ gcc/diagnostic.h(working copy)
@@ -85,10 +85,14 @@ struct diagnostic_context
/* True if we should print the command line option which controls
each diagnostic, if known. */
bool show_option_requested;
+ /* True if we should print the source line with a caret indicating
+ the location. */
+ bool show_caret;
+
/* True if we should raise a SIGABRT on errors. */
bool abort_on_error;
/* This function is called before any message is printed out. It is
responsible for preparing message prefix and such. For example, it
Index: gcc/input.h
===
--- gcc/input.h (revision 132680)
+++ gcc/input.h (working copy)
@@ -39,10 +39,13 @@ typedef struct GTY (())
/* The line-location in the source file. */
int line;
int column;
+
+ /* The offset location in
Re: [PATCH][4.3] Deprecate -ftrapv
Robert Dewar write: >Usually there are ways of telling what is going on at a sufficiently >low level, but in any case, code using the conditional jump instruction >(jo/jno) is hugely better than what we do now (and it is often faster >to usea jo than into). My point is that using INTO or some other processor's overlow mechanism that requires operating system support wouldn't necessarily be better for Ada, even it performs better (or uses less space) than the alternatives. Having the program crash with a vague exception would meet the requirements of -ftrapv, but not Ada. Ross Ridge
Re: [PATCH][4.3] Deprecate -ftrapv
Robert Dewar write: >Usually there are ways of telling what is going on at a sufficiently >low level, but in any case, code using the conditional jump instruction >(jo/jno) is hugely better than what we do now (and it is often faster >to usea jo than into). Ross Ridge wrote: >My point is that using INTO or some other processor's overlow mechanism >that requires operating system support wouldn't necessarily be better for >Ada, even it performs better (or uses less space) than the alternatives. >Having the program crash with a vague exception would meet the >requirements of -ftrapv, but not Ada. Robert Dewar write: >But, once again, using the processor specific JO instruction will be >much better for Ada than double length arithmetic, using JO does not >involve a "program crash with a vague exception". *sigh* The possibility of using GCC's -ftrapv support to implement overlow exceptions in Ada was mentioned in this thread. There's no requirement that -ftrapv do anything other than crash when overflow occurs. A -ftrapv that did everything you've said you wanted, performed faster and caught 100% of overflows 100% reliabily wouldn't necessarily be better for Ada. On the 32-bit IA-32 platform, either the JO instruction or a INTO instruction could legitimately be used to provide a more optimal implementation of -ftrapv. Even the JO instruction could do nothing more than jump to abort(). Ross Ridge
Re: [PATCH][4.3] Deprecate -ftrapv
Robert Dewar write: But, once again, using the processor specific JO instruction will be much better for Ada than double length arithmetic, using JO does not involve a "program crash with a vague exception". *sigh* The possibility of using GCC's -ftrapv support to implement overlow exceptions in Ada was mentioned in this thread. There's no requirement that -ftrapv do anything other than crash when overflow occurs. A -ftrapv that did everything you've said you wanted, performed faster and caught 100% of overflows 100% reliabily wouldn't necessarily be better for Ada. Why not? On the 32-bit IA-32 platform, either the JO instruction or a INTO instruction could legitimately be used to provide a more optimal implementation of -ftrapv. Even the JO instruction could do nothing more than jump to abort(). Yes, and that is what we would want for Ada, so I am puzzled by your sigh. All Ada needs to do is to issue a constraint_error exception, it does not need to know where the exception came from or why except in very broad detail. Ross Ridge there is some miscommmunication here, and I can't figure out what it is!
Re: [PATCH][4.3] Deprecate -ftrapv
Robert Dewar writes: >Yes, and that is what we would want for Ada, so I am puzzled by your >sigh. All Ada needs to do is to issue a constraint_error exception, >it does not need to know where the exception came from or why except >in very broad detail. Unless printing "This application has requested the Runtime to terminate it in an unusual way." counts an issuing a contraint_error in Ada, it seems to me that -ftrapv and Ada have differing requirements. How can you portabilty and correctly generate a constraint_error if the code generated by -ftrapv calls the C runtime function abort()? On Unix-like systems you can catch SIGABRT, but even there how do you tell that it didn't come from CTRL-\, a signal sent from a different process, or abort() called fom some other context? With INTO I don't see any way distignuish the SIGSEGV it generates on Linux from any of the myriad other ways a SIGSEGV can be generated. Ross Ridge
Re: Possible GCC 4.3 driver regression caused by your patch
On Sun, Mar 02, 2008 at 01:17:02PM -0500, Carlos O'Donell wrote: > Greg Schafer wrote: > >Hi Carlos and Mark, > > > >Your "Relocated compiler should not look in $prefix" patch here: > > > >http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html > > > >appears to have caused a regression in my GCC 4.3 testing. > > > >In summary, there is a small window *during the GCC build itself* where GCC > >does not pick up the correct startfiles. For example, when GCC_FOR_TARGET > >is > >called to build the target libraries, the startfiles in $prefix/lib are not > >used. Instead, the startfiles from the host's /usr/lib are used which > >breaks > >my build. Note that the problem seems to rectify itself once the just-built > >GCC is installed into $prefix. > > > >Here's the scenario: > > > > - Native build > > - i686-pc-linux-gnu > > - --prefix=/temptools > > - Glibc already installed in /temptools/lib > > What options did you use to configure the compiler? Could you double > check your host system is actually i686-pc-linux-gnu? When you say > "breaks my build", what error are you seeing? Hi Carlos, The problem boils down to this: - when xgcc is run from $objdir, GCC thinks it is a relocated compiler - your patch changed the behaviour of relocated compilers - therefore your patch also changed the behaviour of GCC when it is run from $objdir eg: when building the target libs. This is the key point that breaks my build. The following patch restores the old behaviour and fixes my build. I suspect what is really needed is for GCC to somehow differentiate when it is being run from $objdir and when it is truly relocated. Thoughts? diff -Naur gcc-4.3.0-RC-20080222.orig/gcc/gcc.c gcc-4.3.0-RC-20080222/gcc/gcc.c --- gcc-4.3.0-RC-20080222.orig/gcc/gcc.c2008-01-24 18:57:12.0 + +++ gcc-4.3.0-RC-20080222/gcc/gcc.c 2008-03-02 06:07:36.0 + @@ -6370,6 +6370,11 @@ machine_suffix, standard_startfile_prefix, NULL), NULL, PREFIX_PRIORITY_LAST, 0, 1); + add_prefix (&startfile_prefixes, + concat (standard_exec_prefix, + machine_suffix, + standard_startfile_prefix, NULL), + NULL, PREFIX_PRIORITY_LAST, 0, 1); } /* Sysrooted prefixes are relocated because target_system_root is For the record, the scenario I quoted initially was contrived to demonstrate the problem. The real breakage happens in a slightly more complicated procedure that involves bootstrapping a 64-bit toolchain from a 32-bit host. Thanks Greg
Re: [PATCH][4.3] Deprecate -ftrapv
Ross Ridge wrote: Robert Dewar writes: Yes, and that is what we would want for Ada, so I am puzzled by your sigh. All Ada needs to do is to issue a constraint_error exception, it does not need to know where the exception came from or why except in very broad detail. Unless printing "This application has requested the Runtime to terminate it in an unusual way." counts an issuing a contraint_error in Ada, it seems to me that -ftrapv and Ada have differing requirements. How can you portabilty and correctly generate a constraint_error if the code generated by -ftrapv calls the C runtime function abort()? On Unix-like systems you can catch SIGABRT, but even there how do you tell that it didn't come from CTRL-\, a signal sent from a different process, or abort() called fom some other context? With INTO I don't see any way distignuish the SIGSEGV it generates on Linux from any of the myriad other ways a SIGSEGV can be generated. The normal action of the Ada run time on encountering a SIGSEGV is to issue a constraint_Error, that's standard, and works fine. There is no requirement for the kind of distinction you are talking about. In answer to the question about abort(), we can certainly override that routine if we need to but I don't think we need to. This of course is OS dependent, but it's the sort of problem we deal with in other contexts on all operating systems. it's fine to have Ctrl-\, signal from a different process or abort() called from some other context generate a constraint error exception if it is not possible to distinguish the cases. Ross Ridge
Re: Excess registers pushed - regs_ever_live not right way?
I gave up with DF and instead went through function tree argument to rediscover argument registers. It was then simple matter to exclude these from epilog/prolog registers saves/restores. The patches is posted - and seem quite portable to other targets. http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00115.html best regards and thanks for help. Seongbae Park (???, ???) wrote: 2008/3/1 Andrew Hutchinson <[EMAIL PROTECTED]>: I'm am still struggling with a good solution that avoids unneeded saves of parameter registers. To solve problem all I need to know are the registers actually used for parameters. Since the caller assumes all of these are clobbered by callee - they should never need to be saved. I'm totally confused what is the problem here. I thought you were seeing extra callee-save register save/restore in prologue, but now it sounds like you're seeing extra caller-save register save/restore. Which one are you trying to solve, and what kind of target is this ? DF_REG_DEF_COUNT is showing 1 artificial def for all POTENTIAL parameter registers - not just the ones that are really used (since it uses target FUNCTION_ARG_REGNO_P to get parameter registers) You said you wanted to know if there's a def of a register within a function. For an incoming parameter, there will be one artificial def, and if there's no other def, it means there's no real def of the register within the function. So the DF artificial defs are useless in trying to find real parameter registers. I don't understand what you mean by this. What do you mean by "real parameter register" ? That seem to require going over all DF chains to work out which registers are externally defined. DF does not solve problem for me. What do you mean by "externally defined" ? DF may not solve the problem for you, but now I'm completely lost on what your problem is. There has got to be an easier way of finding parameter registers used by function. If you want to find all the uses (use as in reading a register but not writing to it), you should look at USE chain, not DEF chain, naturally. Seongbae
Re: Possible GCC 4.3 driver regression caused by your patch
On Mon, Mar 03, 2008 at 09:29:18AM +1100, Greg Schafer wrote: > The following patch restores the old behaviour and fixes my build. I for one would not like to see us go back to the old broken behaviour. One rather nice result of Carlos' fix is that you can now build a sysrooted compiler on a native host without too much trouble. -- Alan Modra Australia Development Lab, IBM
Re: [PATCH][4.3] Deprecate -ftrapv
[EMAIL PROTECTED] (Ross Ridge) writes: > Robert Dewar writes: > >Yes, and that is what we would want for Ada, so I am puzzled by your > >sigh. All Ada needs to do is to issue a constraint_error exception, > >it does not need to know where the exception came from or why except > >in very broad detail. > > Unless printing "This application has requested the Runtime to terminate > it in an unusual way." counts an issuing a contraint_error in Ada, > it seems to me that -ftrapv and Ada have differing requirements. > How can you portabilty and correctly generate a constraint_error if > the code generated by -ftrapv calls the C runtime function abort()? > On Unix-like systems you can catch SIGABRT, but even there how do you > tell that it didn't come from CTRL-\, a signal sent from a different > process, or abort() called fom some other context? With INTO I don't > see any way distignuish the SIGSEGV it generates on Linux from any of > the myriad other ways a SIGSEGV can be generated. Easy: The signal frame that is passed as an argument to the signal handler has a trapno member than will contain 4 for INTO. The only other case where it would contain 4 would be a explicit int 4 -Andi
Re: [PATCH][4.3] Deprecate -ftrapv
Andi Kleen wrote: [EMAIL PROTECTED] (Ross Ridge) writes: Easy: The signal frame that is passed as an argument to the signal handler has a trapno member than will contain 4 for INTO. The only other case where it would contain 4 would be a explicit int 4 OK, so that's exactly what is needed in the Ada case, thanks Andi for investigating (it was hard to believe there was no way :-)) -Andi
Re: [PATCH][4.3] Deprecate -ftrapv
Ross Ridge writes: > On Unix-like systems you can catch SIGABRT, but even there how do you > tell that it didn't come from CTRL-\... Oops, I forgot that CTRL-\ had it own signal SIGQUIT. Ross Ridge
Re: [PATCH][4.3] Deprecate -ftrapv
Ross Ridge wrote: Ross Ridge writes: On Unix-like systems you can catch SIGABRT, but even there how do you tell that it didn't come from CTRL-\... Oops, I forgot that CTRL-\ had it own signal SIGQUIT. Ross Ridge In fact I suspect that once you stop sighing and look carefully, there will be ways of distinguishing the various cases. That's certainly been our experience in the past :-)
Re: optimizing predictable branches on x86
On Wednesday 27 February 2008 03:06, J.C. Pizarro wrote: > Compiling and executing the code of Nick Piggin at > http://gcc.gnu.org/ml/gcc/2008-02/msg00601.html > > in my old Athlon64 Venice 3200+ 2.0 GHz, > 3 GiB DDR400, 32-bit kernel, gcc 3.4.6, i got > > $ gcc -O3 -falign-functions=64 -falign-loops=64 -falign-jumps=64 > -falign-labels=64 -march=i686 foo.c -o foo > $ ./foo > no deps, predictable -- Ccode took 10.08ns per iteration > no deps, predictable -- cmov code took 11.07ns per iteration > no deps, predictable -- jmp code took 11.25ns per iteration > has deps, predictable -- Ccode took 26.66ns per iteration > has deps, predictable -- cmov code took 35.44ns per iteration > has deps, predictable -- jmp code took 18.89ns per iteration > no deps, unpredictable -- Ccode took 10.17ns per iteration > no deps, unpredictable -- cmov code took 11.07ns per iteration > no deps, unpredictable -- jmp code took 22.51ns per iteration > has deps, unpredictable -- Ccode took 104.02ns per iteration > has deps, unpredictable -- cmov code took 107.19ns per iteration > has deps, unpredictable -- jmp code took 176.18ns per iteration Thanks for the numbers... just be careful, sometimes the numbers are a bit funny: eg. "C" should be very similar code as "cmov", but sometimes the numbers vary more than I'd like (eg. 26 vs 35ns case) which I guess is due to gcc having better control over the code generation in the C case. This should apply to jmp as well, and indeed if I compile for i586 (without cmov), then the C code uses jmp, and can be even slightly faster than my jmp asm. So this is really a demonstration / guideline only, and I think it would have to be implemented natively in gcc before you can look really closely at the numbers. Thanks, Nick
