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

(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?

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>

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)

[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)

[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)

[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)

[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: (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)

[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)

[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)

[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.