X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.2 required=5.0	tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,TW_BG
X-Spam-Check-By: sourceware.org
Message-ID: <4D8A472C.7040708@cwilson.fastmail.fm>
Date: Wed, 23 Mar 2011 15:17:00 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
Reply-To: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: cyggfortran-3.dll broken ?
References: <AANLkTi=WaAY1HY2bZ2zKHHuCkpNE4oLCZ8cY1J=CV1Ma AT mail DOT gmail DOT com>	<4D8A1775 DOT 5020601 AT gmail DOT com>	<4D8A1BCD DOT 2080506 AT gmail DOT com> <AANLkTinGfQi2ad4yTbDydrzbURQATtTT4zVJWG01V5LS AT mail DOT gmail DOT com> <4D8A214D DOT 6090409 AT cwilson DOT fastmail DOT fm> <4D8A2683 DOT 1010009 AT gmail DOT com> <4D8A2E5F DOT 1040204 AT cwilson DOT fastmail DOT fm> <4D8A32B6 DOT 9050507 AT gmail DOT com>
In-Reply-To: <4D8A32B6.9050507@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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

On 3/23/2011 1:49 PM, Dave Korn wrote:
> On 23/03/2011 17:31, Charles Wilson wrote:
> 
>> Err...no, I don't think so.  Symbol forwarding is actually implemented
>> as part of the PE-I386 spec, so it resides in the forwardING dll itself,
>> not the import library, and is handled at runtime by the windows loader:
> 
>   Yes yes yes, you're jumping too far ahead; what I was pointing out is that
> you still have to have an import stub in order to pull in the import from the
> forwarding DLL.

True -- you must have stubs in libgfortran.a *if* you want newly
compiled clients to use (whatever is in cyggfortran-3.dll, whether an
actual implementation or a pe-i386 windows-loader-supported forwarding
operation) instead of just resolving the symbol directly at link time
via libcygwin.a/cygwin1.dll.

>> However, by NOT having a thunk present in the import library, then when
>> linking a new client the symbol will be resolved by libcygwin.a and will
>> show up in the new client's import list as coming directly from cygwin1.dll.
> 
>   Well that seems like it would be cleaner in theory, but it would still
> constitute a change to the ABI exported by libgfortran

Not really.  The ABI applies to the DLL, which would still have export
entries for all the symbols. It's just that some of them would be
forwarding entries.

If you removed the stubs for those functions now "implemented" as
forwards, from libgfortran.dll.a (or removed the static impls from
libgfortran.a) it is technically an ABI change, but one that doesn't
REALLY matter, because you know those symbols will be provided by
libcygwin.a for newly compiled clients.

The limitation would come in that the new gfortran library system, and
any (new) apps compiled with it, would require to be built and run only
on cygwin-1.7.8 or newer.

But that's nothing "new" -- this happens all the time (and it's true
already, thanks to the fenv issue).  Dunno if the gcc devs want to
ensconce that idea in their code, tho (see below).

> which is what we were
> trying to avoid; if we're keeping the ABI constant, then future fortran apps
> linked against libgfortran should also continue to get their math functions
> from there rather than cygwin1.

Well, maybe. Ugly...

>   We'd want to keep the forwarders in place forever

Yeah, I know.  That's what I'd like to avoid: permanent workarounds
originally required because of a cygwin deficiency, long since rectified.

> and here's the good thing
> about how it works: regardless which dll.a the import stub comes from and how
> many DLLs it does or doesn't forward through before it reaches the actual
> implementation, that's all indirected away by the loader and at run-time it's
> still just a single indirect jump in both cases.

True, the additional runtime cost is zero.

>   Hmm, I should probably do this.  And send it upstream too.

Well, yeah (but does upstream want to explicitly require cygwin-1.7.8 or
better? or would you conditionalize it on a configure test: add
forwarders if cgywin1.dll new enough and has the funcs, otherwise add
the .o's and local impl to libgfortran.)

> But I'll
> prioritise it lower than bringing newer compiler versions onstream unless we
> start to get a lot of problem reports.

Since octave & company are the only known clients, and marco's already
started a respin, sure...

--
Chuck


--
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