This is the mail archive of the cygwin mailing list for the Cygwin 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: cyggfortran-3.dll broken ?


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


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