This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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] --enable-dynamic-string default for mingw-w64


On 9/20/2011 10:12 AM, Kai Tietz wrote:
> 2011/9/20 Charles Wilson <xxx@yyy.com>:

http://cygwin.com/acronyms/index.html#PCYMTNQREAIYR

>> So, this would be a change in current mingw.org behavior.  I *was*
>> under the impression that this workaround for the old "can't pass
>> empty strings across DLL boundary" problem[1] was no longer necessary
>> in the gcc-4.x era, but I haven't tested the proposition.  Was I wrong
>> about that?
> 
> Yes.  If you read last comment of the thread you are citing, then you
> would notice that for static-libstdc++ version the issue is still
> present.  So to allow users to use also static-libstdc++ variant, this
> option is still necessary.

Thanks for the clarification.  So, we (mingw.org) really should have
been using this all along, to support users of -static-libstdc++ [*]

>> I'm not really opposed to making this change for i*86-pc-mingw -- and
>> now's the time to do it, as the recently released 4.6.1 mingw.org gcc
>> broke the C++ abi anyway, thanks to thiscall.
> 
> Here I am a bit curious?  How is 4.6.1 affected by new thiscall
> calling-convention?  Is it just its presence in 4.6.x, or what?  As
> the thiscall-convention ABI change for C++ is done in 4.7.x only, and
> 4.6.x shouldn't be affected by it.

Ah, I misunderstood the previous conversation.  My belief, at the end of
that conversation, was that while the ABI of libstdc++-6.dll did not
change in 4.6 (e.g. /THAT/ library wasn't affected by the new thiscall
support), other C++ DLLs compiled using that compiler might see ABI
changes due to thiscall.

However, if in 4.6 thiscall must be explicitly activated --
__attribute__(thiscall) or somesuch, I assume -- and otherwise has no
effect, then of course you're right: 4.6 imposes no ABI breakage on mingw.

In that case, I suggest we (mingw.org) focus on maintaining ABI
stability in our official releases in the 4.6 series, and plan to impose
all the ABI changes (that we know of) when 4.7 is released:

	1) --enable-fully-dynamic-string
	2) thiscall
	3) winpthreads?
	4) anything else?  SEH???

In the context of the patch under discussion at gcc-patches, that means
only making --enable-fully-dynamic-string the default for
i?86-pc-mingw32 in 4.7+, and not backporting to 4.6-.

=====> side discussion ====>
[*] We haven't been too kind to the "fully static" users (e.g both
-static-libstdc++ AND -static-libgcc).  As you know, without TDM's
special patches [**], the i?86-pc-mingw32 compiler doesn't allow to
throw exceptions across DLL boundaries unless using libgcc_s.dll --
there was hope that this could be remedied (without resorting to
"horrible" patches) back in 2009 SoC [1] but that was never completed.

[**] forward ports of Danny's self-described "horrible" patches to the
3.4.x series to enable exceptions-across-dll-bounds.  We've (mingw.org)
have been VERY hesitant to go back down that road, as the patches were
in essence a fork, since they would "never be merged upstream" according
to Danny.  This was the main reason mingw.org's official gcc releases
were "stuck" at 3.4.x during the entire 4.0, 4.1, AND 4.2 cycles --
hence our skittishness at doing something like that again.

[1]
http://gcc.gnu.org/wiki/WindowsGCCImprovementsGSoC2008#Exceptions_across_DLL
<===== side discussion <======

--
Chuck


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