eh interface questions

[DE-DINECHIN,CHRISTOPHE (HP-Cupertino,ex1)]

> From: owner-cxx-abi at corp.sgi.com [mailto:owner-cxx-abi at corp.sgi.com]
> On Behalf Of Richard Henderson
> Sent: Thursday, February 22, 2001 10:47 AM
> To: cxx-abi at corp.sgi.com
> Cc: Richard Henderson
> Subject: eh interface questions
> 
> 
> ]  typedef void (*_Unwind_Exception_Cleanup_Fn)
> ]              (_Unwind_Reason_Code reason,
> ]               struct _Unwind_Exception *exc);
> 
> What is the purpose of the reason code here?  Yes, once can indicate
> why someone other than the normal language runtime is deleting the
> exception, but what's the point?

The following reason codes are documented:

*	_URC_FOREIGN_EXCEPTION_CAUGHT = 1: This indicates that a different
runtime caught this exception. Nested foreign exceptions, or rethrowing a
foreign exception, result in undefined behaviour. 

*	_URC_FATAL_PHASE1_ERROR = 3: The personality routine encountered an
error during phase 1, other than the specific error codes defined. 

*	_URC_FATAL_PHASE2_ERROR = 2: The personality routine encountered an
error during phase 2, for instance a stack corruption. 


For a C++ runtime, for instance, reason codes 2 and 3 should result in
"terminate()" being called. Reason code 1 should not.


> ]  _Unwind_Reason_Code (*__personality_routine)
> ]          (int version,
> ]           _Unwind_Action actions,
> ]           uint64 exceptionClass,
> ]           struct _Unwind_Exception *exceptionObject,
> ]           struct _Unwind_Context *context);
> 
> Why bother passing exceptionClass here (and to _Unwind_Stop_Fn) when
> it is available in exceptionObject->exception_class?  And come to 
> think of is, what sort of exceptionClass should 
> longjmp_unwind provide?

The reason we passed the exception class is 
1-historical, because it used to not be in the exception object 
2- for convenience because most personality routines will have to check the
exception class at the beginning

> 
> ]  uint64 _Unwind_GetRegionStart
> ]          (struct _Unwind_Context *context);
> 
> This is all well and good for function-relative code addresses, but
> what about data addresses?  The HP LSDA, for instance, contains
> GP-relative pointers to type_info objects.  That GP base is of course
> for the target DSO, not necessarily the current DSO.
> 
> Given that HPUX and AIX (for example) don't respect a fixed offset
> between text and data segments, certainly something of this nature
> is required.

GP is also stored in the UnwindContext as register GR1.


Regards
Christophe