Re: [PATCH] [cygwin] Refactor C++ exception handling for Win32 correctness

[Charles Wilson]

On 6/20/2010 1:33 PM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Sun, Jun 20, 2010 at 06:59:02AM CEST:
>> There are ODR issues with the definition of the exception class(es).
>> While on linux, the code may technically be in violation, in practice
>> it is ok and works.
> 
> But that's not OK.  As much as possible, we want our tests to abide by
> the relevant standards, the C++ one here.  We want tests to work on all
> conforming platforms, not just those we happen to test right now[1].
> There is no need to word the comment before the test in a way that
> frames it as a pure w32 thing if it isn't:
> 
>> +# However, for simplicity, the refactoring of modexc into a separate
>> +# library is done for all platforms.
> 
> This can go.  Please mention in the comment that not using a common lib
> represents an ODR violation (mentioning relevant terms from standards is
> helpful).
> 
> BTW, does not using the same strategy for liba represent an ODR
> violation as well?  If yes, then we should fix that, too.

How about this change (I believe it answers both of your concerns, above)

-# library. This treatment is not necessary for liba (e.g. the libexc
-# exception class), because that library is not dynamically loaded.
-# However, for simplicity, the refactoring of modexc into a separate
-# library is done for all platforms.
+# library. Not using a 'common' library in this manner represents an
+# ODR violation, unless the platform's runtime loader is capable of
+# rationalizing vague linkage items such as vtables, typeinfo, and
+# typename elements) at runtime.  The Win32 loader is not capable of
+# this, but some ELF loaders appear to be.
+#
+# Similar treatment is not necessary for liba (e.g. the libexc
+# exception class), because that library is not dynamically loaded. As a
+# consequence, vague linkage items for the class libexc are resolved at
+# link time using the vague linkage rules, for both Win32 and other
+# (e.g. ELF) platforms.

>> OK to push?
> 
> Given above comments are addressed, and there are no objections from
> others within 48 hours, yes.
> 
> [1] And I specifically don't want to see them break with LTO, just
>     because we got away with some violation before.

As I state above, you only get an ODR violation if the linker (or the
runtime loader) can't coalesce multiple vague linkage items together
when necessary.  ELF linkers and loaders can, at either or both linktime
and runtime. The PE/COFF linker can, but the loader can't -- so we have
to use other means to prevent ODR violations when dynamically loading
DLLs whose interface involves entities with constituents requiring vague
linkage.

But -- as far as I can tell -- only on PE/COFF (maybe AIX?), and only
for dynamically loading DLLs, as opposed to explicitly linking against
them, so long as you've done the whole dllimport/dllexport dance (which
we now do).

If you DON'T do the dance, then...I'm not sure.

I'm going to try to get cygwin's resident gcc/binutils export, Dave K,
to weigh in on this thread before checking anything in.

--
Chuck