X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=p7
	LyjSEsZTyPrnXY+MLyR/iik1U22zusCXIBwEQXyX2kncdwuC5AyTu34Q47HbSOfm
	ccVmxgEOwmaO/utzOAW3zZdL/+zzv+5mXgLFam0HW+SbY8kzYswVl1YwYu0p9rgQ
	4RZcFUu1VOy5DoZq6C/JVBh1pLl3A1RXKBhKwKPcw=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; s=default; bh=4tYhHMO2
	6mLNglpul0DUae6SvT0=; b=xN3atGQgC7GpnQ6hOZpDs16JgsxcwJKGVBzeVpS8
	1NnAHg7p5SpuXs4osQ1wslvSf/j5jORd5xUjMp1SVyl32k7/PMxsl7UwOsPsgMn6
	bXMo+U1sRaBDPGP24fI45YRTSyal9YUyvRixFgoM6P/foNJQNx4FhFnbQqDkm6cI
	WrA=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	mail-qa0-f46.google.com
MIME-Version:	1.0
X-Received:	by 10.224.4.73 with SMTP id 9mr15404071qaq.12.1406207313307; Thu, 24 Jul 2014 06:08:33 -0700 (PDT)
In-Reply-To:	<20140722132001.GD27005@calimero.vinschen.de>
References:	<20140715130829 DOT GK10401 AT calimero DOT vinschen DOT de> <53C532D9 DOT 7050506 AT gmail DOT com> <20140715143915 DOT GA8330 AT calimero DOT vinschen DOT de> <20140716070231 DOT GA25020 AT calimero DOT vinschen DOT de> <53C6F68A DOT 9000801 AT gmail DOT com> <20140717073734 DOT GA15332 AT calimero DOT vinschen DOT de> <53C7EC48 DOT 5060903 AT dronecode DOT org DOT uk> <20140717182429 DOT GS15332 AT calimero DOT vinschen DOT de> <20140722082711 DOT GA22860 AT calimero DOT vinschen DOT de> <53CE604D DOT 1070309 AT dronecode DOT org DOT uk> <20140722132001 DOT GD27005 AT calimero DOT vinschen DOT de>
Date:	Thu, 24 Jul 2014 15:08:33 +0200
Message-ID:	<CAEwic4aBPee5ojhAb9zYh95P3b8VJfXsZBefEGRkBU5SHnpX8w@mail.gmail.com>
Subject:	Re: Core dump on 32-bit Cygwin if program calls dlopen
From:	Kai Tietz <ktietz70 AT googlemail DOT com>
To:	cygwin AT cygwin DOT com, DJ Delorie <dj AT redhat DOT com>,
	Kai Tietz <ktietz AT redhat DOT com>
X-IsSubscribed:	yes

2014-07-22 15:20 GMT+02:00 Corinna Vinschen wrote:
> On Jul 22 13:59, Jon TURNEY wrote:
>> On 22/07/2014 09:27, Corinna Vinschen wrote:
>> >On Jul 17 20:24, Corinna Vinschen wrote:
>> >>On Jul 17 16:31, Jon TURNEY wrote:
>> >>>On 17/07/2014 08:37, Corinna Vinschen wrote:
>> >>>>It's the libgcc DLL which gives us grief, so a new libgcc package is
>> >>>>sufficent, afaics.  We should check if this DLL fixes the problem and
>> >>>>then make it "curr" soon, I think.
>> >>>
>> >>>I briefly tested this other patch with my test case from the mail above, and
>> >>>it doesn't seem to help.
>> >>>[...]
>> >>I asked DJ to take another look, but I guess ultimately we need the
>> >>attention of one of the GCC Windows maintainers.  Kai Tietz seems to be
>> >>unavailable right now, unfortunately.
>> >
>> >Looks like I totally misunderstood DJ's patch.  The patch does *not*
>> >change libgcc, it changes cygmin-crtbegin.c, thus the crtbegin.o file
>> >which is statically linked into the executable.
>> >
>> >That means, to fix the issue, you don't have to replace libgcc, you
>> >have to recompile the executable against the new crtbegin.o.
>> >
>> >DJ still claims his patch is the correct one.  The simple testcase
>> >dlopen'ing cyggs-9.dll works fine with the new crtbegin.o, according to
>> >him.
>>
>> Sorry, I hadn't tested it correctly.
>
> No worries, this was my fault.  Talking about building a new libgcc
> rather than building a new crtbegin.o was bound to lead everyone
> off track :|
>
>> Building my test with an updated crtbegin.o as well, my test case is fixed.
>
> Nice!
>
>> I agree this patch seems better than my suggested one, as it makes crtbegin
>> do the right thing in the face of unbalanced libgcc load/unload, rather than
>> attempting to balance the libgcc load/unload as mine does.
>
> Ok.  I CC'ed DJ so he knows all is good, and then we probably need a
> windows GCC maintainer to approve the patch I guess.  Kai?  Ping?
>

Hi  Corinna

As I we spoke yesterday on irc, I took already a look to DJ's patch
and it is sensible.  If DJ sends patch upstream to gcc's ML, and put
me CC, I will review it asap.

Thanks,
Kai

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -