This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


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

Re: [RFA] pei386 dll: auto-import patch


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




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