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

[Ralf Wildenhues]

* Charles Wilson wrote on Wed, Jun 23, 2010 at 06:17:41AM CEST:
> On 6/20/2010 1:33 PM, Ralf Wildenhues wrote:
> > 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)

Yes, it does, thank you!

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

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

FWIW, AIX already passes the test with the patch you have applied so
far; well, it fails the installed run test over an unrelated bug in
that module.so isn't installed, but that's been reported elsewhere,
and will be fixed elsewhere.

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

More feedback is always good, but from my side the patch is good to go
with the above folded in.

Thanks,
Ralf