This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [RFA] pei386 dll: auto-import patch
- To: Paul Sokolovsky <Paul dot Sokolovsky at technologist dot com>
- Subject: Re: [RFA] pei386 dll: auto-import patch
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- Date: Sat, 04 Aug 2001 18:38:55 -0400
- CC: Robert Collins <robert dot collins at itdomain dot com dot au>,Danny Smith <danny_r_smith_2001 at yahoo dot co dot nz>,binutils at sources dot redhat dot com
- References: <616.010805@technologist.com>
Paul Sokolovsky wrote:
> Gentlemen,
>
> Thanks for all your work on supporting and lobbying the
> patch in question. Thanks to binutils maintainers for accepting it
> (heh, it was committed on a right day - I had birthday then, it was a
> good present, thanks ;-) ). Sorry that I didn't participate in the
> discussion - I was in the other city with little chance to access my
> mail and with no access to my devel machine.
>
> I don't have much time to study related threads thoroughly,
> but from quick skimming I would like to add some
> comments/clarifications/opinions on some subjects (but please note
> that I might miss some info or misunderstand the point due to surface
> review):
>
> 1. I never posted auto-import patch on binutils maillist. It was
> available from the mingw distro and I passed it to Ralf Habacker
> (Cygwin KDE porter). While he was testing it, he found issue with
> repetitive auto-importing of some symbols leading to segfaults. It
> was fixed and passed back to him. He confirmed it fixed issue and
> reported that some reasonable subset of kde core and sample apps were
> build with and were running.
I *believe* Ralf and Robert Collins were in contact. "My" version, was
based on *Robert's* version, which he got from Ralf, who was up-to-date
with your most recent version. So, I *think* that what was finally
committed WAS in fact, up-to-date with your stuff. Except...
> I'm currently cvs-updating my local copy of binutils to check if I
> have any pending changes.
I really hacked up the auto_export() function, so you'll have some
problems merging that. My changes, at DJ's suggestion, do the
auto_export() based on a few tables, rather than 25 or so ad-hoc tests.
> 2. Presuppositions for using auto-import
>
> To use aut-import, you must have new-fashion import library [for those
> symbols which gets auto-imported], period. New-fashion implibs are
> produced by the new (auto-import-patched) ld. Hence, auto-import won't
> work with:
>
> 2.1. implibs made by old ld
> 2.2. implibs made by dlltool
>
> Additionally, it won't work when:
>
> 2.3. linking directly against dll
>
> The last case may need to be fixed somewhen.
The "auto-import" feature won't work in those cases, naturally.
However, the ld WILL successfully link "old-style" code with "old-style"
implibs or with dll directly (functional interface only, just as
before). IOW, the new ld is drop-in replacement for old ld, given same
sourcecode/object files/dlls/implibs.
In OTHER other words, if you don't TRY to use the auto-import feature,
you won't get burned. :-) It's just that there are cases where
auto-import won't work (usually forward-compatibility problems, cf 2.1
or 2.2).
> When auto-import linking with unsupported implibs will be requested,
> you'll get undefineds of _nm_* or something.
A-HA! a pre-made FAQ. Q: "I can't link to -lfoo. I get "symbol _nm_*
undefined" A: "you need to recompile libfoo, or change your source code
to use __declspec(dllimport). BTW, the original porter of libfoo
probably fixed the libfoo include headers to do this for you; did you
forget to -Ddefine something? Read the porter's notes for libfoo."
> 3. auto-import vs auto-export
>
> Well, those are totally different and unrelated (rather, orthogonal)
> features. Their names are not confusing, IMHO. Consider yourself:
>
> 3.1. auto-export about *exporting* (sic) symbols from some PE image.
> The usual way of exporting is marking symbols explicitly and manually
> as such (via __declspec() or .def). auto-export does the job
> automatically, by exporting all symbols except ones which can be
> proved to be only of internal usage or mere junk.
>
> The switch which activates auto-export feature is --export-all-symbols
> (commonly abbreviated as --export-all)
Also, not specifiying a .def file AND not
__declspec(dllexport)-decorating your source code == same effect as
explicitly stating --export-all. (I call this "implicit" --export-all)
>
> 3.2. auto-import about *importing* (sic) [data] symbols into some PE
> image. The usual way of importing data symbols is marking them
> explicitly as such with __declspec(). auto-import allows to skip this,
> by importing data automatically.
>
> The switch which activates the feature is --enable-auto-import .
>
>
> So, from my point of view, mere names imply clearly that they
> are distinct, in some way symmetrical, and those names quite close
> describe their operation. The only confusion is that features and
> corresponding commandline options are named differently, but that's
> another issue.
Yes, but: in practice you are more likely to USE auto-export (e.g.
--export-all) now that auto-import works. Soooo...they are tied
together, somewhat. For instance, now you don't have to worry too much
about creating a .def file and/or decorating exports when you want a dll
of some library -- principle of least effort sez that newly ported libs
(dlls) will NOT "do it the hard way"; --export-all (implicit?) will see
much more use in the future, IMO.
All made possible by auto-import.
> Also, there should be no problems with using --export-all and
> --enable-auto-import during the same link, the meaning is: resolve
> symbols using auto-import feature; export all suitable symbols to the
> resulting image. If any problems with the combination exist, it's a
> bug or issue with particular linking environment (like C++).
Yep.
> 4. I have no idea what may cause problems with elaborated C++ stuff
> (containing templates, etc.). The first thing to check is place where
> segfault happens - in OS linker or in app startup. If the latter is
> the case, then, as Danny Smith points out, it may be an issue with C++
> dlls at all, and not just with auto-import.
That's my suspicion.
--Chuck