[Libreoffice-commits] Resolves: #i123747# allow treating Window's SEH events as C++ exceptions

[Stephan Bergmann]

On 11/26/2013 10:27 AM, Stephan Bergmann wrote:
> Is this sound?  I am no expert with Windows SEH, does it actually
> guarantee that the low-level process state is also a valid state at the
> higher-level C++ semantics when a SEH exception is thrown?  (That would
> be a prerequisite for this patch, and e.g. the missing guarantee about
> that consistency for C/POSIX signals is the reason why we cannot
> automatically translate such signals into C++ exceptions.)

So there is /EHa (enabling C++ to catch asynchronous (SEH) exceptions) 
vs. /EHs (allowing C++ to only catch C++ (synchronous) exceptions), and 
we're currently using /EHa, and that presumably makes the #i123747# 
patch work.

However, /EHa does at least have a space overhead (and 
<http://stackoverflow.com/a/4415711> claims it also has a time overhead 
on x86), see below, so my natural reaction would be to switch to /EHs 
and be happy.  (After all, SEH exceptions are a result of invoking 
undefined behavior at the C++ level, and its a fallacy to assume you can 
meaningfully interact with that at the C++ level in general.  And little 
if any of our code base would apparently depend on it, given that an 
/EHs "make check" works, as detailed below.)

However, as other parts of that stackoverflow page allude to, there may 
be implications for interaction with the CLR, i.e., for our CLI-UNO 
bridge.  I'd hoped to verify that with the 
testtools/source/bridgetest/cli/ code, but that's apparently rotting 
dead at least since gbuild'ification, and I ditched my fruitless 
attempts to revive it after an hour of frustration...  Anybody else 
wanting to pick that up?

Anyway, for the record, here's how I measured impact of /EHa vs. /EHs 
vs. /EHsc (which additionally assumes that C functions never throw C++ 
exceptions) on current master (at rev. 
2fbf95f5efb0e7e2781fa8546845a084721ee4e7).  The build is implicitly 
--disable-debug --disable-dbgutil, but I had to explicitly --disable-lto 
because I only had a 32bit Windows 7 available and that isn't able to 
give the linker enough heap to do LTO on our huge libraries.

It is the definition of gb_LinkTarget_EXCEPTIONFLAGS in 
solenv/gbuild/platform/com_MSC_defs.mk that specifies -EHa, and I 
exchanged that with -EHs and -EHsc, resp., and measured the sizes of all 
instdir *.com, *.dll, and *.exe files for each case (forgot to include 
*.bin, too).  The attached eh.ods gives the detailed numbers; there is a 
roughly 20% decrease in overall binary file size from /EHa to /EHs, 
while there is only little further decrease towards /EHsc.

To make all three builds work, I had to apply the attached eh.patch:
* Compiling /clr code apparently explicitly requires /EHa (and 
specifying /EHa after /EHs[c] only results in a linker warning and uses 
/EHa).
* The #i123747# patch's _set_se_translator requires /EHa (and this is 
about reverting it anyway).
* Some function definitions in winaccessibility are boilerplate-armored 
with try/catch(...) around their bodies even if those are known to not 
throw any (C++) exceptions, and the compiler warns about that under 
/EHs[c], so I needed to silence that for --enable-werror.

Stephan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eh.ods
Type: application/vnd.oasis.opendocument.spreadsheet
Size: 41287 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20131204/8d87a9a3/attachment.ods>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eh.patch
Type: text/x-patch
Size: 11771 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20131204/8d87a9a3/attachment.bin>