|
|
2009/3/21 Christopher Faylor <cgf-use-the-mailinglist-please@xxxxxxx>:
> On Sat, Mar 21, 2009 at 06:08:16PM +0100, Kai Tietz wrote:
>>2009/3/21 Christopher Faylor <cgf-use-the-mailinglist-please@xxxxxxx>:
>>> On Fri, Mar 20, 2009 at 09:59:56AM +0100, Kai Tietz wrote:
>>>>Jakub Jelinek <jakub@xxxxxxxxxx> wrote on 20.03.2009 09:42:27:
>>>>>On Fri, Mar 20, 2009 at 01:24:52AM -0400, NightStrike wrote:
>>>>>>>This is OK by me, but please wait until 4.5, since this is not a
>>>>>regression.
>>>>>>>Danny
>>>>>>
>>>>>>GCC 4.3 definitely worked as it should, without having a broken front
>>>>>>end. ?Why would you want to deliver 4.4 with a completely broken driver
>>>>>>for win64, when it worked earlier? ?The patch isn't tagged as a
>>>>>>regression, but it definitely is.
>>>>>
>>>>>I think this should be applied for 4.4 as well.
>>>>
>>>>Well, I think so, too. ?This name collision is now a pretty old issue
>>>>(which was reported by many users on our sites, especially if they want
>>>>to link vc static libraries to gcc projects or static libraries from
>>>>gcc to vc projects). ?And as this patch keeps for 32-bit the old name,
>>>>I see not much reasons to prevent this patch for 4.4. ?Christopher,
>>>>what is your opinion about this?
>>>
>>> Your patch seems to presuppose that there are no existing users of the
>>> mingw 64 toolchain who could be using __chkstk. ?Is that really the
>>> case?
>>>
>>> I'm also not clear on what changed to make this an issue for 4.4.
>>
>>We have users on mingw-w64, which are trying to use vc libraries
>>together with our runtime. Reasoned by the name conflict in symbol
>>__chkstk they weren't able to do this. Because gcc produced code uses
>>__chkstk in the semantics to probe and allocate memory and vc uses it
>>in the semantics to just probe stack. Btw this is the reason why
>>cygwin, mingw.org, and now we too don't export the __chkstk symbol
>>from ntdll.dll and kernel32.dll. IMHO this is a hack, which I want to
>>revert again on our 64-bit runtime as soon as possible.
>>
>>Btw the user reported that he had the same problems for mingw.org
>>toolchain. Reasoned by Danny's wish, I readded the __chkstk symbol for
>>32-bit to gcc's stack-probing implementation.
>
> Yes, I know that you made it conditional on 32-bit.
>
>>So by this patch I want to avoid that there are users, which are using
>>the symbol __chkstk in gcc's variation, so that there aren't any
>>problems in future about changing this.
>
> I still don't know what *changed* to make this an urgent request for gcc
> 4.4, especially since, as you say, it's a hack. Is this just something
> that has been recently noticed? You seemed to be implying that
> everything was ok for gcc 4.3.
>
> cgf
>
>
Not me. AFAIK NightStrike just mentioned that for 4.3 the issue didn't
happened. I assume it is poped up by using shared libgcc, because here
the symbol get in conflict with the exports of kernel32.dll and
ntdll.dll (we provided in our runtime). So the bug was already
present, but it's present just showed up in 4.4.
Just by this reason NightStrike sees this as regression and I can't
say that this is wrong from an user point of view. It seems to me that
this is a bug with a long history.
For me it is not urgent, but we have to life with that hack in our crt
for the long time of 4.4 and we come to same catch 22 situation I
would like to avoid. so I would like to see it 4.4. And it fixes a
latent bug also for 32-bit win32 targets, present now for a long time.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
|
|