This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch PR libstdc++/51135]: Fix [4.7 Regression] SIGSEGV during exception cleanup on win32


2011/12/8 Jonathan Wakely <jwakely.gcc@gmail.com>:
> On Dec 8, 2011 7:16 PM, "Kai Tietz" wrote:
>>
>> ? ? ? ?* unwind-cxx.h (__cxa_exception): Use for member
>> ? ? ? ?exceptionDestructor the _GLIBCXX_DESTRUCTOR_CALLCONVENTION macro.
>
> I think "Use the _GLIBCXX_DESTRUCTOR_CALLCONVENTION macro for the
> exceptionDestructor member" would make more sense.

Thanks, I will add it to ChangeLog that way, if the macro variant is
selected by maintainer of that code.

> However ...
>
>> 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__)
>> +#define _GLIBCXX_DESTRUCTOR_CALLCONVENTION __thiscall
>> +#else
>> +#define _GLIBCXX_DESTRUCTOR_CALLCONVENTION
>> +#endif
>
> Could you define a typedef for void(*)(void*) and adapt that for
> mingw32 instead of using the macro everywhere?
>
> #if defined (__MINGW32__) && defined (__i386__)
> typedef void (__thiscall *__cxxabi_dtor_type)(void*);
> #else
> typedef void (*__cxxabi_dtor_type)(void*);
> #endif
>
> (That would be my preference, but the maintainers of that code might disagree.)

Well, sure.  Might be even a more clear way to have here an explicit
type-name indicating arguments kind.  But code-maintainer should tell,
what variant is preferred here.

Kai


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]