Re: Exception-safety for C++ code integrated with Guile.

[Taahir Ahmed <ahmed.taahir@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]

> mingw.org's MinGW uses DWARF exception handling.  Perhaps you are
> thinking of MinGW64, which (AFAIK) indeed uses eh by default, but can
> be configured to use DWARF.

I was under the impression that MinGW only used setjump/longjump exception 
handling, with plans to move to Windows SEH.  Either way, it's neither here 
nor there.

> As for libunwind, are you sure it supports enough platforms to be a
> useful alternative?  AFAIK, the last official release supports only
> IA-64, and even the current development version in git repo basically
> supports GNU/Linux and almost nothing else (2 FreeBSD targets and 1 on
> HP-UX).

The documentation of the last official release (v1.1, in 2012) only mentions 
ia64, but it appears to actually support the same list of platforms as the 
current version.

From looking at the libunwind source, the only os-dependent code is a single 
function for looking through an elf image.  The rest of the code is written 
once for each architecture (more specifically, once for each 
architecture/calling convention tuple).

What are the platforms that Guile supports? (I can't find a comprehensive list 
anywhere).  In _scm.h, I can see special casing of sj/lj for vms, cray(!!), 
and ia64.  There's no need to change the behavior for vms and cray.  The ia64 
special casing is simply to force all registers to be saved, which is easy to 
handle.  It seems reasonable that all other cases will be covered by libunwind 
(or at least, libunwind with some small modifications).

Of course, if testing uncovers an os/arch tuple that doesn't work, one can 
simply fall back to the standard system sj/lj, and not having C++ cleanup 
behavior on those platforms.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]