From: Luke D. <cod...@ho...> - 2004-09-07 13:03:30
|
I have to agree with everything Aaron says here. I believe that the "internal name" feature was never intended to resolve differences between compilers and it should not be hacked to make this work. The "correct" way for .def files to work is however the MS tools work. It would be useful to have a way to generate import libraries where the symbol names differ from the names in the import table (.idata$6), which is what "--kill-at" does but in an inflexible way. However, I do not think we should change or extend the syntax of .def files to achieve this because there are already too many hacks (e.g. --add-stdcall-alias, --kill-at, --enable-stdcall-fixup, etc.). In theory, a new tool could be developed that can generate an import library where the symbol name defined in the import library can be chosen independently of the corresponding name in the import table (.idata$6). It may even be possible to do this as a shell script that generates and compiles some assembly language. Luke ----- Original Message ----- From: "Aaron W. LaFramboise" <aar...@aa...> To: <min...@li...> Sent: Tuesday, September 07, 2004 10:18 AM Subject: Re: [Mingw-users] dlltool.c (was: Announcement: Binutils-2.15.91-20040902 1 Release candidate) > This thread has become long and tedious, but I think it is important to > ensure that binutil's behavior is correct, so I would hope you work with > me to come to a mutual understanding and agreement. > > Carlo Wood wrote: >>>dll_implementation.c: void joe() {} >>>dll.def: bob=joe >>>dll_user.c: extern void bob(); // ... > >>>3) User code name: this is also _bob, in dll_user.o, and unfortunately >> >> Of course this is _bob ?! How could it be anthing else? >> It must be the same symbol or else it would never link >> with the import library. > > Note that #2 refers to a dynamic symbol, and that #3 refers an object > symbol. That is, #2 is what appears in .idata, and in the DLL's EAT. > #3 is a PECOFF object (not image) symbol, appearing in the object symbol > table, that appears in the import library (.a or .lib) and is usually > removed in a final release build. > > #1 (the internal name) is meaningless for import library creation, as > the internal name of the symbol within the DLL is not visible and has > absolutely no affect at this layer of abstraction. That is why dlltool > (previously) and MS LINK and LIB ignore the internal name when creating > import libraries. > > Ordinarily, with a single export in appears in the .def: > ONE > #2 and #3 are both set to _ONE. > > If this is changed to the following: > LEFT=RIGHT > your changes to binutils cause #2 to be set to RIGHT, and #3 set to > LEFT. What should happen (and happened before, and happens with > Microsoft's tools) is that both #2 and #3 be set to _ONE, as above, and > the internal name be ignored (in this context). > >> Also, the internal name (joe) *is* was appears in idata$6 section >> of the import library... so now I think again that my patch *is* >> correct :/ > > No. The internal name does not appear in the import library (the .a or > .lib) at all. Check it against MS LINK and LIB if you don't beleive me. > In other words, if a DLL is built, but all debug symbols are stripped, > and its sources are deleted, internal name refers to something that no > longer exists. > > The = sign in the .def is used to specify the binding between the PECOFF > object symbol in the DLL's source objects and the dynamic exported > symbol in the DLL. It does not specify the binding between that > exported symbol and the PECOFF object symbol in the import library > (which is the same name as used in the source file), as your patch > causes it to. > >> But you say that the internal name is not used when creating >> the import library... how is that possible? Then it is impossible >> to ever call joe. > > The runtime binding is to the exported name, not the internal name, > which are not always the same, thanks to the proper meaning of =. > > Perhaps part of the confusion here is that PE images (DLLs and EXEs) > have multiple symbols. There is the normal symbol table, which is only > used for debugging purposes, and not used for symbol resolution. Then > there is the export address table, which is what is used for the > run-/load-time binding. Due to .def files, it is common for these two > symbol names to differ, often to strip off stdcall decorators, but > sometimes for other things. > >> I think you should look at my smalltest.tar.gz. >> This is going nowhere :/ > > I would like to figure out how to make your code work. However, without > msvc.dll (which was not included), it is difficult to debug your code to > figure out whats going wrong. > > Thanks for your thoughtful consideration, > > Aaron W. LaFramboise > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |