Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Mike Stump]

> From: Anthony Green <green@cygnus.com>
> Date: 28 Jan 2000 13:23:20 -0800

> There are real opportunities to mess things up right now because
> glibc does not use the same exception mechanisms that we use in GCC.

> I discussed this with Ulrich recently.  It seems that the ideal
> situation is to have glibc use some kind of structured exception
> handling scheme in C which will generate the same EH bits that
> g++/gcj use.

:-) I guess it is time for someone to expose the existing machinery in
the compiler to the C language.  All the semantics are already there.
All the backend code is already there.  All the hard work has been
done.  What remains is to invent a syntax and wire it up.  Glue code
if you will.

If someone wants a cool project, and wants to be forever blamed for
exception handling in C, I'd even provide pointers, tricks and
details...  Step on up, don't be shy.

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[David Edelsohn]

>>>>> Mike Stump writes:

Mike> :-) I guess it is time for someone to expose the existing machinery in
Mike> the compiler to the C language.  All the semantics are already there.
Mike> All the backend code is already there.  All the hard work has been
Mike> done.  What remains is to invent a syntax and wire it up.  Glue code
Mike> if you will.

Mike> If someone wants a cool project, and wants to be forever blamed for
Mike> exception handling in C, I'd even provide pointers, tricks and
Mike> details...  Step on up, don't be shy.

	Not that we necessarily want to follow their design, but Microsoft
already has a definition of exception handling in C and there is a source
code base using that definition.

David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Marc Lehmann]

On Fri, Jan 28, 2000 at 05:13:36PM -0500, David Edelsohn <dje@watson.ibm.com> wrote:
> 	Not that we necessarily want to follow their design, but Microsoft
> already has a definition of exception handling in C and there is a source
> code base using that definition.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Marc Lehmann]

> > > 	Not that we necessarily want to follow their design, but Microsoft
> > > already has a definition of exception handling in C and there is a source
> > > code base using that definition.
> 
> And, where's your reply? :-)))

Hmm, good idea ;) The single line that was missing should have read:

[David:] Could you sent an example, if you have hone?

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@opengroup.org |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[David Edelsohn]

>>>>> Marc Lehmann writes:

Marc> Could you send an example, if you have one?

	I am not an expert on Microsoft C Structured Exception Handling,
but it basically is the same syntax as in the C++ standard (adapted from
Modula-2+).

The additional keywords are:

try
except
finally
leave


Here are some examples that someone sent me a long time ago:

try {
    do {
        try {
            delta = f(delta, ...);
        }
        except (GetExceptionCode() == STATUS_FLOATING_OVERFLOW) {
            delta = 0.0;
        }
    } while (delta > epsilon);
}
except (1) {
    return failure_status;
}


try {
    // initialize resources, no allocation
    try {
        // allocate resources
	// do work
    }
    finally {
        // free resources
    }
}
except (GetExceptionCode() == FAIL) {
    // log error
    return failure;
}
return success;


David

Re: GCC testing questions

[Mike Stump]

> From: gary@Intrepid.Com (Gary Funck)
> Date: Mon, 24 Apr 2000 17:18:38 -0700

> We're doing some work with an older 2.7.2 based GCC

Let me urge you to re-port and move up to a more current release.
2.95.2 is the current release.

> The client using the compiler asked how the compiler is tested, and
> we noted that we had run version 1.44 of the c-torture tests because
> those were the ones available at the time.

This is generally my take on testing as well.  However, some would
also include the notion that you should test with the most current
testsuite, and go though those results so that you can see all the
known to current date failures in your compiler, instead of just the
known some old date failures.

The questions you ask (they ask) are in general hard to answer, but
they are good questions.  I don't even have good answers for them.
I use the metric, <30 getting close, >400 total failure, ~100 still
needs lots of work.  Personally, if I were release manager for gcc, I
would rather use the phrase == 0, ok, != 0 needs work, and then just
pony up the work required to make this happen, but as I know all too
well, getting the numbers down is a really, really hard job that takes
years after you decide to try.

Good luck.

Re: GCC testing questions

[Gary Funck]

On Apr 24,  5:57pm, Mike Stump wrote:
> Subject: Re: GCC testing questions
> > From: gary@Intrepid.Com (Gary Funck)
> > Date: Mon, 24 Apr 2000 17:18:38 -0700
> 
> > We're doing some work with an older 2.7.2 based GCC
> 
> Let me urge you to re-port and move up to a more current release.
> 2.95.2 is the current release.
> 
> > The client using the compiler asked how the compiler is tested, and
> > we noted that we had run version 1.44 of the c-torture tests because
> > those were the ones available at the time.
> 
> This is generally my take on testing as well.  However, some would
> also include the notion that you should test with the most current
> testsuite, and go though those results so that you can see all the
> known to current date failures in your compiler, instead of just the
> known some old date failures.
> 
> The questions you ask (they ask) are in general hard to answer, but
> they are good questions.  I don't even have good answers for them.
> I use the metric, <30 getting close, >400 total failure, ~100 still
> needs lots of work.  Personally, if I were release manager for gcc, I
> would rather use the phrase == 0, ok, != 0 needs work, and then just
> pony up the work required to make this happen, but as I know all too
> well, getting the numbers down is a really, really hard job that takes
> years after you decide to try.

Thanks, Mike.  Those are good suggestions.  It won't be
possible moving to the latest GCC because the current
build of the product passes its tests, and going with
new tools would potentially increase risk, and extend
the schedule.  Your answer spoke to what level of passing
might be considered adequate (ie, less than 10 failures),
but not exactly what standard is used by the GCC community
to determine when the base compiler is "done" and is
ready for deployment on the major platforms (what _are_
those major platforms? <g>).

Re: GCC testing questions

[Robert Lipe]

> > > From: gary@Intrepid.Com (Gary Funck) 
> > > We're doing some work with an older 2.7.2 based GCC
[ ... ]
> > > The client using the compiler asked how the compiler is tested,
>
> Thanks, Mike.  Those are good suggestions.  It won't be possible
> moving to the latest GCC because the current build of the product
> passes its tests, and going with new tools would potentially increase
> risk, and extend

The hardball answer is that if changing the compiler introduces risk of
product failure then your testing is inadequate. :-)

> Your answer spoke to what level of passing might be considered
> adequate (ie, less than 10 failures), but not exactly what standard
> is used by the GCC community to determine when the base compiler is
> "done" and is ready for deployment on the major platforms (what _are_
> those major platforms? <g>).

The answers were different in the 2.7 era.  (I think they were much
more fuzzy then, too.)  

Even for the modern releases, since the "acceptable" failures vary
from target to target, there isn't a fixed answer.  It's the reality
of a multi-architecture compiler like GCC that different failures
will show on different targets.  We go through this exercise on major
releases.  The last major release of GCC was 2.95.  Reference:
http://gcc.gnu.org/gcc-2.95/gcc-2.95.2.html .

Follow the link to 'regress.html'.  That shows the list of targets that
were considered major at the time.  It was a goal that the last release
(1.1.2) would have the 2.95 testsuite run on all the major targets and
that the goal was to have zero regressions from 1.1.2.  (It looks like
one of my targets was the only one to blemish that shiny goal.)  There
are probably a few hundred thousand cominbations exercised.

There are also links showing which architectures were reported to work
even they didn't run the testsuite and sign up for the "no regressions"
target.

The big-name testsuites carry serious licensing costs and restrictions.
Therefore the public releases aren't formally certified as passing
those.  However, there are companies with licenses to use that do run
those suites and can provide certified GCC releases if it's important
enough to you.  Of course, the better citizens feed back any changes
necessary to pass the suites, so the reality is that the code generally
stays pretty conformant.

RJL

Re: GCC testing questions

[Martin v. Loewis]

> but not exactly what standard is used by the GCC community
> to determine when the base compiler is "done" and is
> ready for deployment on the major platforms

Please have a look at the draft for the GCC 3 release criteria, at

http://gcc.gnu.org/gcc-3.0/criteria.html

It has the definitions of major platforms, major supported software,
and regression tests results.

Regards,
Martin

Re: GCC testing questions

[Jeffrey A Law]

  In message < 200004261840.UAA01699@loewis.home.cs.tu-berlin.de >you write:
  > > but not exactly what standard is used by the GCC community
  > > to determine when the base compiler is "done" and is
  > > ready for deployment on the major platforms
  > 
  > Please have a look at the draft for the GCC 3 release criteria, at
  > 
  > http://gcc.gnu.org/gcc-3.0/criteria.html
  > 
  > It has the definitions of major platforms, major supported software,
  > and regression tests results.
Also note it is possible to get information on some of the previous releases
off the web page to:

http://gcc.gnu.org/gcc-2.95/regress.html
http://gcc.gnu.org/egcs-1.1/regress.html
http://gcc.gnu.org/egcs-1.0/buildstat.html




  > 
  > Regards,
  > Martin
  > 
  > 

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Mike Stump]

> Date: Mon, 31 Jan 2000 18:25:02 -0600
> From: David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu>

> Interesting. Wouldn't it be better just to add C++ exception
> handling, though?

Yeah, I think this is a good idea.  An existing International Standard
is a whee bit better that some usoft extension.  Though, C will need
__try and __catch as well.

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[llewelly]

On Mon, 31 Jan 2000, David Starner wrote:

> On Mon, Jan 31, 2000 at 03:45:44PM -0800, Bill Tutt wrote:
> > The Microsoft exception handling in C syntax is described at: (SEH)
> > http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_exception_handling_topics_.28.seh.29.htm
> > 
> > The relavent keywords are: __try, __except, and __finally.
> 
> Interesting. Wouldn't it be better just to add C++ exception handling, though?
> It's substantially the same, but C++ EH is more general and has clear effects
> with C++ EH over current implementations. Less of a learning curve for most
> people, and if anyone needs Microsoft EH, it shouldn't be that hard to port 
> over.
> 

As a C++ programmer, I would prefer the C++ EH syntax and semantics,
  assuming EH should be provided as a gnu extension to C. I also think the
  C++ syntax is more widely known. It is also more similar to the java
  exception syntax. ( catch(...) { throw; } => finally { } is one of the
  few changes. (by the way, since C does not have destructors, it would
  be nice if the info page section on exceptions for C described
  catch(...) { throw; } , as every C programmer that uses exceptions will
  need to know about it. ) )

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[David Starner]

On Mon, Jan 31, 2000 at 03:45:44PM -0800, Bill Tutt wrote:
> The Microsoft exception handling in C syntax is described at: (SEH)
> http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_exception_handling_topics_.28.seh.29.htm
> 
> The relavent keywords are: __try, __except, and __finally.

Interesting. Wouldn't it be better just to add C++ exception handling, though?
It's substantially the same, but C++ EH is more general and has clear effects
with C++ EH over current implementations. Less of a learning curve for most
people, and if anyone needs Microsoft EH, it shouldn't be that hard to port 
over.

-- 
David Starner - dstarner98@aasaa.ofe.org
If you wish to strive for peace of soul then believe; 
if you wish to be a devotee of truth, then inquire.
   -- Friedrich Nietzsche

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Bill Tutt]

The Microsoft exception handling in C syntax is described at: (SEH)
http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_exception_handling_topics_.28.seh.29.htm

The relavent keywords are: __try, __except, and __finally.

Example __try/__except code:

__try {
    float x, y=0;
    x = 5 / y;        // This exception handled by outer block
    __try {
        x = 0;
        y = 27 / x;   // This exception handled by inner block
    }
    __except( GetExceptionCode() == STATUS_FLOATING_DIVIDE_BY_ZERO) {
        printf("handled by inner block");
    }
}
__except( GetExceptionCode() == STATUS_FLOATING_DIVIDE_BY_ZERO ) {
    printf( "handled by outer block" );
}

The return value of the __except filter is treated specially.
If it returns 1, the except block is executed.
If it returns 0, the exception handler search continues.
If it returns -1, the exception is dismissed and execution continues
at the point the exception originally occurred.

GetExceptionCode() is required to appear in the filter expression, any
function called in the filter can't call GetExceptionCode() and expect
to get the correct value.

If you want to raise a specfic SEH exception manually, you use the
RaiseException() function.

A __try/__finally handler works as one would expect.

example code:

void *pv = NULL;

__try
{
  pv = malloc(1);
  .....
}
__finally
{
  if (pv) free(pv);
}

The AbnormalTermination returns TRUE in the __finally block if indeed
the block was executed due to an exception being thrown, otherwise it
returns FALSE.

Other wierd details:
You can't use a goto to jump into a __try or __finally block.  You
can't nest __try/__except or __try/__finally handlers inside a
__finally block.

The only other relavent detail being that you should observe caution
when using goto, or return to exit a __finally block.

SEH are asynchronous exceptions, so they adversly effect the
optimization opportunities, use them with care.

For information on how SEH and C++ exceptions interact check out the
MSDN docs on the subject:

http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_exception_handling_differences.htm

For the gorey details of how SEH actually gets implemented check out:
http://msdn.microsoft.com/library/periodic/period97/pietrek.htm

Hope this explains things,
Bill

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Anthony Green]

Godmar wrote:
>  - change the gcc driver to pick the threading system you'd like to use
>    when linking an executable.

On many systems there are extra complications.  I'll use Linux as an
example.  There are real opportunities to mess things up right now
because glibc does not use the same exception mechanisms that we use
in GCC.  My most recent experience with this was in libgcj.  We used
to throw an exception from the pthread cancellation callback.  This
doesn't work :-)

Fortunately that part of the java spec was deprecated so we took it
out of our implementation.

I discussed this with Ulrich recently.  It seems that the ideal
situation is to have glibc use some kind of structured exception
handling scheme in C which will generate the same EH bits that g++/gcj
use.  In this case when you throw an exception through a glibc
callback, all of the various glibc/libio cleanups happen in addition
to user code.

My point is that you may be forced to use a particular implementation
on some systems for safety sake.

AG

-- 
Anthony Green                                                        Red Hat
                                                       Sunnyvale, California

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Godmar Back]

> 
> >>>>> Geoffrey Keating writes:
> 
> Geoff> I don't remember what the problem with threads and sj/lj
> Geoff> exceptions is, but that isn't it.
> 
> 	It is more likely that libgcc2.a or some other library were not
> compiled thread-safe.  We have not wanted to create yet another set of
> multilib version of the libraries for thread-safe use.
> 

I too am bothered that the choice of a threading system with which libgcc2.a
interacts is a configuration parameter to gcc.

I acknowledge that it allows the inlining of frequently used thread 
operations, such as retrieving thread-specific data, but I think it
comes with a lot of drawbacks.

Here's how I would like to see threading in libgcc handled:

 - add support for a generic threading system that is indirected
   through a function pointer table.  The gthr interface could be a good
   basis for defining this interface.  This will allow the use of other
   than the handful of supported threading systems without changes 
   to the gcc source.

 - change the configuration system to not only build one version, but
   to build multiple versions.  For instance, you could build a 
   libgcc_singlethread, libgcc_posix, and libgcc_generic, etc.. (*)

   This will allow to have a single gcc installation to provide support
   for multiple thread systems.  Currently, one requires two completely
   separate gcc installation just to support say threaded and non-threaded
   Java.

 - change the gcc driver to pick the threading system you'd like to use
   when linking an executable.


    - Godmar

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[David Edelsohn]

>>>>> Geoffrey Keating writes:

Geoff> I don't remember what the problem with threads and sj/lj
Geoff> exceptions is, but that isn't it.

	It is more likely that libgcc2.a or some other library were not
compiled thread-safe.  We have not wanted to create yet another set of
multilib version of the libraries for thread-safe use.

David

Re: (lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Geoff Keating]

The following message is a courtesy copy of an article
that has been posted to cygnus.egcs as well.

Stuart Jarriel <sjarriel@motive.com> writes:

> From my niave reading of the libgcc2.a code it seems that AIX can
> only use setjmp/longjmp exception handling due to the lack of
> necessary stack unwinding support.

This is true at present, but will be different very soon.

> If this is true, is it possible to affect the generated assembly
> code to use thread-safe registers?  The stack unwind code seems to
> use registers r9 & r11 to walk the eh_context structure.  The
> Power[PC] calling conventions show those registers to be volatile
> across a context switch, and I assume the same is true across a
> thread switch.

They're volatile across procedure calls (in fact, r9 is an
argument-passing register).  They are not clobbered at random by the
OS.  I don't remember what the problem with threads and sj/lj
exceptions is, but that isn't it.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

(lack of) Thread-safe exceptions on AIX (gcc-2.95.1)

[Stuart Jarriel]

From my niave reading of the libgcc2.a code it seems that AIX can only
use
setjmp/longjmp exception handling due to the lack of necessary stack 
unwinding support.

If this is true, is it possible to affect the generated assembly code to
use
thread-safe registers?  The stack unwind code seems to use registers r9
& r11
to walk the eh_context structure.  The Power[PC] calling conventions
show those
registers to be volatile across a context switch, and I assume the same
is true
across a thread switch.  

Im looking for a way to force the registers used in the exception unwind
code 
to be non-volatile (rN > 16).

Any advice or suggestions?