| Message ID | CAEwic4bO3Bb5WR6-U=6n6FPNoukjTJYowpzpjWb+-feSbzNyWA@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On 12/12/2011 12:11 PM, Kai Tietz wrote: > Hi, > > so as no other review happend, I changed patch as you suggested. Well, sorry for not noticing earlier, but here, as in many other cases, I think it would be much cleaner to have the pre-processor games in the mingw config header, define a macro name there (normally undefined) and then use it here. Paolo.
2011/12/12 Paolo Carlini <paolo.carlini@oracle.com>: > On 12/12/2011 12:11 PM, Kai Tietz wrote: >> >> Hi, >> >> so as no other review happend, I changed patch as you suggested. > > Well, sorry for not noticing earlier, but here, as in many other cases, I > think it would be much cleaner to have the pre-processor games in the mingw > config header, define a macro name there (normally undefined) and then use > it here. > > Paolo. Well, this was my initial attempt to solve it. The issue here is that libsupc++ doesn't use the the os-header-file and I am not sure if it is wise to introduce it here. To add it to the cxxabi.h header, which claims to reflect ABI issue, looks sensible as alternative to me here. Kai
On 12/12/2011 12:29 PM, Kai Tietz wrote: > Well, this was my initial attempt to solve it. The issue here is that > libsupc++ doesn't use the the os-header-file Are you sure? Should include bits/c++config.h, no? Paolo.
2011/12/12 Paolo Carlini <paolo.carlini@oracle.com>: > On 12/12/2011 12:29 PM, Kai Tietz wrote: >> >> Well, this was my initial attempt to solve it. The issue here is that >> libsupc++ doesn't use the the os-header-file > > Are you sure? Should include bits/c++config.h, no? > > Paolo. Well, I tested it, and I saw that the define in the os part for libsupc++ weren't set. By looking into this, this might be also caused by not including in all .cc files using cxxabi.h before bits/c++config.h. Kai
2011/12/12 Kai Tietz <ktietz70@googlemail.com>: > 2011/12/12 Paolo Carlini <paolo.carlini@oracle.com>: >> On 12/12/2011 12:29 PM, Kai Tietz wrote: >>> >>> Well, this was my initial attempt to solve it. The issue here is that >>> libsupc++ doesn't use the the os-header-file >> >> Are you sure? Should include bits/c++config.h, no? >> >> Paolo. > > Well, I tested it, and I saw that the define in the os part for > libsupc++ weren't set. By looking into this, this might be also > caused by not including in all .cc files using cxxabi.h before > bits/c++config.h. > > Kai Hmm, strange. cxxabi.h is supposed to include <bits/c++config.h> itself. I will retest Kai
On 12 December 2011 11:29, Kai Tietz <ktietz70@googlemail.com> wrote: > 2011/12/12 Paolo Carlini <paolo.carlini@oracle.com>: >> On 12/12/2011 12:11 PM, Kai Tietz wrote: >>> >>> Hi, >>> >>> so as no other review happend, I changed patch as you suggested. >> >> Well, sorry for not noticing earlier, but here, as in many other cases, I >> think it would be much cleaner to have the pre-processor games in the mingw >> config header, define a macro name there (normally undefined) and then use >> it here. >> >> Paolo. > > Well, this was my initial attempt to solve it. The issue here is that > libsupc++ doesn't use the the os-header-file and I am not sure if it > is wise to introduce it here. To add it to the cxxabi.h header, which > claims to reflect ABI issue, looks sensible as alternative to me here. I think Paolo means: #ifdef _GLIBCXX_USE_THISCALL_ON_DTOR typedef void (__thiscall *__cxxabi_dtor_type) (void *); #else typedef void (*__cxxabi_dtor_type) (void *); #endif instead of testing __MINGW32__ and __i386__ Also, my suggestion of __cxxabi_dtor_type would be more consistent it was spelled __cxa not __cxxabi (sorry, it was just a quick suggestion, not a request to actually use that name!)
On 12/12/2011 12:50 PM, Jonathan Wakely wrote: > I think Paolo means: > > #ifdef _GLIBCXX_USE_THISCALL_ON_DTOR > typedef void (__thiscall *__cxxabi_dtor_type) (void *); > #else > typedef void (*__cxxabi_dtor_type) (void *); > #endif > > instead of testing __MINGW32__ and __i386__ This for sure, but I think we could as well move the whole thing in the config file, like: #ifndef _GLIBCXX_USE_THISCALL_ON_DTOR typedef void (*__cxxabi_dtor_type) (void *); #endif Paolo.
2011/12/12 Paolo Carlini <paolo.carlini@oracle.com>: > On 12/12/2011 12:50 PM, Jonathan Wakely wrote: >> >> I think Paolo means: >> >> #ifdef _GLIBCXX_USE_THISCALL_ON_DTOR >> typedef void (__thiscall *__cxxabi_dtor_type) (void *); >> #else >> typedef void (*__cxxabi_dtor_type) (void *); >> #endif >> >> instead of testing __MINGW32__ and __i386__ > > This for sure, but I think we could as well move the whole thing in the > config file, like: > > #ifndef _GLIBCXX_USE_THISCALL_ON_DTOR > > typedef void (*__cxxabi_dtor_type) (void *); > #endif > > Paolo. Fine, nevertheless the test in os-config file for __i386__ is required, as just for IA 32-bit this calling convention is for interest. Neither x64 nor ARM etc requires it. Kai
On 12/12/2011 12:58 PM, Kai Tietz wrote: > Fine, nevertheless the test in os-config file for __i386__ is > required, as just for IA 32-bit this calling convention is for > interest. Neither x64 nor ARM etc requires it. So - just out of curiosity, ultimately you are responsible for the config files - why we do have separate mingw32 and mingw32-w64 configs? Paolo.
2011/12/12 Paolo Carlini <paolo.carlini@oracle.com>: > On 12/12/2011 12:58 PM, Kai Tietz wrote: >> >> Fine, nevertheless the test in os-config file for __i386__ is required, as >> just for IA 32-bit this calling convention is for interest. Neither x64 nor >> ARM etc requires it. > > So - just out of curiosity, ultimately you are responsible for the config > files - why we do have separate mingw32 and mingw32-w64 configs? > > Paolo. Well, this is mainly caused by different feature-set of runtimes. We could solve things here also by probing for specific runtimes and so using just on configure tree. Kai
On 12/12/2011 01:19 PM, Kai Tietz wrote: > Well, this is mainly caused by different feature-set of runtimes. We > could solve things here also by probing for specific runtimes and so > using just on configure tree. Ah, thus, it's *not* true that mingw32, at variance with mingw32-w64, is only used for i386? Anyway, as I said already, in the config files you can check all the macros you like ;) Paolo.
Index: gcc/libstdc++-v3/libsupc++/cxxabi.h =================================================================== --- gcc.orig/libstdc++-v3/libsupc++/cxxabi.h +++ gcc/libstdc++-v3/libsupc++/cxxabi.h @@ -51,6 +51,16 @@ #include <bits/cxxabi_tweaks.h> #include <bits/cxxabi_forced.h> +// On 32-bit IA native windows target is the used calling-convention +// for class-member-functions of kind __thiscall. As destructor is +// also of kind class-member-function, we need to specify for this +// target proper calling-convention on destructor-function-pointer. +#if defined (__MINGW32__) && defined (__i386__) +typedef void (__thiscall *__cxxabi_dtor_type) (void *); +#else +typedef void (*__cxxabi_dtor_type) (void *); +#endif + #ifdef __cplusplus namespace __cxxabiv1 { @@ -596,7 +606,7 @@ namespace __cxxabiv1 // Throw the exception. void - __cxa_throw(void*, std::type_info*, void (*) (void *)) + __cxa_throw(void*, std::type_info*, __cxxabi_dtor_type) __attribute__((__noreturn__)); // Used to implement exception handlers. Index: gcc/libstdc++-v3/libsupc++/eh_throw.cc =================================================================== --- gcc.orig/libstdc++-v3/libsupc++/eh_throw.cc +++ gcc/libstdc++-v3/libsupc++/eh_throw.cc @@ -58,8 +58,8 @@ __gxx_exception_cleanup (_Unwind_Reason_ extern "C" void -__cxxabiv1::__cxa_throw (void *obj, std::type_info *tinfo, - void (*dest) (void *)) +__cxxabiv1::__cxa_throw (void *obj, std::type_info *tinfo, + __cxxabi_dtor_type dest) { // Definitely a primary. __cxa_refcounted_exception *header Index: gcc/libstdc++-v3/libsupc++/unwind-cxx.h =================================================================== --- gcc.orig/libstdc++-v3/libsupc++/unwind-cxx.h +++ gcc/libstdc++-v3/libsupc++/unwind-cxx.h @@ -51,7 +51,7 @@ struct __cxa_exception { // Manage the exception object itself. std::type_info *exceptionType; - void (*exceptionDestructor)(void *); + __cxxabi_dtor_type exceptionDestructor; // The C++ standard has entertaining rules wrt calling set_terminate // and set_unexpected in the middle of the exception cleanup process.