From: Danny S. <dan...@cl...> - 2004-09-03 10:03:51
|
I have uploaded update of binutils (2.15.90-20040902-1) to MinGW's Sourceforge File Release page. You can download it from: https://sourceforge.net/project/showfiles.php?group_id=2435 The 2.15.90-20040902-1 snapshot incorporates modifications to official binutils CVS since last update. Of note is the addition of Dwarf 2/3 debug support for windows targets. Support for weak symbols has also been added: This is still a WIP. Please refer ChangeLog entries in src for specific changes For more info on binutils, follow this: http://sources.redhat.com/binutils/ Danny 2004-09-03 |
From: Greg C. <chi...@mi...> - 2004-09-03 13:17:58
|
Danny Smith wrote: > I have uploaded update of binutils (2.15.90-20040902-1) > > Of note is the addition of Dwarf 2/3 debug support for windows targets. In this message from Sun, 05 Oct 2003 05:51:40 +1000 http://article.gmane.org/gmane.comp.gnu.mingw.user/9232/match=dwarf+sjlj you said | Just a small clarification. Throwing C++ exceptions across | dll boundaries does work with Dwarf 2. Other thins don't (yet), | the main problem being throwing exceptions from functions that use | W32api callbacks. Does that "main problem" still exist, or is it something we should beware? |
From: Oscar F. <of...@wa...> - 2004-09-03 16:33:56
|
Greg Chicares <chi...@mi...> writes: > Danny Smith wrote: >> I have uploaded update of binutils (2.15.90-20040902-1) >> Of note is the addition of Dwarf 2/3 debug support for windows >> targets. > > In this message from Sun, 05 Oct 2003 05:51:40 +1000 > http://article.gmane.org/gmane.comp.gnu.mingw.user/9232/match=dwarf+sjlj > you said > > | Just a small clarification. Throwing C++ exceptions across > | dll boundaries does work with Dwarf 2. Other thins don't (yet), > | the main problem being throwing exceptions from functions that use > | W32api callbacks. > > Does that "main problem" still exist, or is it something > we should beware? As I read Danny's message, he says Dwarf2 *debugging* information is supported by this binutils RC, not that Dwarf2 *unwinding* information for C++ exceptions is introduced. Moreover, Dwarf2 usage for C++ exceptions is a compiler thing, mainly, AFAIK. It was supported on the early g++ 3.x MinGW releases. -- Oscar |
From: Aaron W. L. <aar...@aa...> - 2004-09-03 20:18:01
|
Danny Smith wrote: > Support for weak symbols has also been added: This is still a WIP. ... pending a patch that I really need to submit really soon. Please don't use them yet. They will randomly not work in some cases. Sorry. Aaron W. LaFramboise |
From: Hartmut B. <har...@gm...> - 2004-09-04 00:35:23
|
Hi, something is wrong in dlltool. Linking against an import library which = was created with dlltool from a def file adds always the @-symbol (like @KfLowerIrql@4 or HalInitSystem@8) to the imported names of the link = target. The parameter '--kill-at' doesn't help. Creating the import library with dlltool 2.15.90 solves this problem. - Hartmut=20 > -----Original Message----- > From: min...@li...=20 > [mailto:min...@li...] On Behalf Of=20 > Danny Smith > Sent: Friday, September 03, 2004 11:58 AM > To: Mingw > Subject: [Mingw-users] Announcement:=20 > Binutils-2.15.91-20040902 1 Release candidate >=20 >=20 > I have uploaded update of binutils (2.15.90-20040902-1) > to MinGW's Sourceforge File Release page. You can download it > from: >=20 > https://sourceforge.net/project/showfiles.php?group_id=3D2435 >=20 > The 2.15.90-20040902-1 snapshot incorporates modifications to=20 > official binutils CVS since last update. >=20 > Of note is the addition of Dwarf 2/3 debug support for=20 > windows targets. Support for weak symbols has also been=20 > added: This is still a WIP.=20 >=20 > Please refer ChangeLog entries in src for specific changes >=20 > For more info on binutils, follow this:=20 > http://sources.redhat.com/binutils/ >=20 > Danny >=20 > 2004-09-03 >=20 >=20 >=20 > ------------------------------------------------------- > 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.=20 > http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick > _______________________________________________ > MinGW-users mailing list > Min...@li... >=20 > You may change your MinGW Account Options or unsubscribe at:=20 > https://lists.sourceforge.net/lists/listinfo/mingw-users >=20 |
From: Danny S. <dan...@cl...> - 2004-09-04 01:59:26
|
----- Original Message ----- From: "Hartmut Birr" Hi, something is wrong in dlltool. Linking against an import library which was created with dlltool from a def file adds always the @-symbol (like @KfLowerIrql@4 or HalInitSystem@8) to the imported names of the link target. Yup, I've reported this to binutils list. I'll upload a fixed version tomorrow. Danny |
From: Carlo W. <ca...@al...> - 2004-09-04 03:31:19
|
On Sat, Sep 04, 2004 at 02:35:09AM +0200, Hartmut Birr wrote: > Hi, > > something is wrong in dlltool. Linking against an import library which was > created with dlltool from a def file adds always the @-symbol (like > @KfLowerIrql@4 or HalInitSystem@8) to the imported names of the link target. > The parameter '--kill-at' doesn't help. Creating the import library with > dlltool 2.15.90 solves this problem. > > - Hartmut Are you sure the .def file doesn't contain explicit aliases? I recently submitted a patch for dlltool that change the behaviour a bit (actually correction wrong behaviour). If now the .def file contains: exportedname = internalname@8 Then --kill-at will be ignored and the 'internalname@8' will be used as specified. If the .def file contains no 'alias', like: HalInitSystem@8 THEN --kill-at should use 'HalInitSystem@8' as exported name (visible to the application, exported from .lib / dll.a) but 'HalInitSystem' as internal name (which can be seen with link.exe -dump -exported foo.dll ) Regards, -- Carlo Wood <ca...@al...> PS The old behaviour was that the '= ...' part was completely ignored. |
From: Danny S. <dan...@cl...> - 2004-09-04 06:56:43
|
----- Original Message ----- From: "Carlo Wood" | Are you sure the .def file doesn't contain explicit aliases? | I recently submitted a patch for dlltool that change the | behaviour a bit (actually correction wrong behaviour). | Have a look at line 903 in dlltool.c and see why implibs are broken now. Danny |
From: Carlo W. <ca...@al...> - 2004-09-04 13:05:25
|
On Sat, Sep 04, 2004 at 06:51:32PM +1200, Danny Smith wrote: > > ----- Original Message ----- > From: "Carlo Wood" > | Are you sure the .def file doesn't contain explicit aliases? > | I recently submitted a patch for dlltool that change the > | behaviour a bit (actually correction wrong behaviour). > | > > Have a look at line 903 in dlltool.c and see why implibs are broken > now. > Danny I'd like to, but I cannot find the binutils that you put on SF. Where did you put it? -- Carlo Wood <ca...@al...> |
From: Hartmut B. <har...@gm...> - 2004-09-04 23:41:12
|
> -----Original Message----- > From: min...@li...=20 > [mailto:min...@li...] On Behalf Of=20 > Danny Smith > Sent: Saturday, September 04, 2004 8:52 AM > To: min...@li... > Subject: Re: [Mingw-users] Announcement:=20 > Binutils-2.15.91-20040902 1 Release candidate >=20 >=20 > Have a look at line 903 in dlltool.c and see why implibs are=20 > broken now. Danny >=20 Hi, I think that line 903 in dlltool.c is not the problem. If I print the = import libraries, I see a difference in the IDATA6 section. I think that the problem is in dlltool.c at line 2520-2527. - Hartmut=20 2.15.90: dctbs00000.o: file format pe-i386 Contents of section .text: 0000 ff250000 00009090 .%...... Contents of section .idata$7: 0000 00000000 .... Contents of section .idata$5: 0000 00000000 .... Contents of section .idata$4: 0000 00000000 .... Contents of section .idata$6: 0000 00004578 41637175 69726546 6173744d ..ExAcquireFastM 0010 75746578 0000 utex.. 2.15.91: gvbs00000.o: file format pe-i386 ontents of section .text: 0000 ff250000 00009090 .%...... ontents of section .idata$7: 0000 00000000 .... ontents of section .idata$5: 0000 00000000 .... ontents of section .idata$4: 0000 00000000 .... ontents of section .idata$6: 0000 00004045 78416371 75697265 46617374 ..@ExAcquireFast 0010 4d757465 78403400 Mutex@4. *** E:\Sandbox\binutils-2.15.90-20040222-1\binutils\dlltool.c Sun Feb 22 05:25:50 2004 --- E:\Sandbox\binutils-2.15.91-20040902-1\binutils\dlltool.c Fri Sep 03 00:37:50 2004 *** 2475,2490 **** why it did that, and it does not match what I see in programs compiled with the MS tools. */ int idx =3D exp->hint; ! si->size =3D strlen (xlate (exp->name)) + 3; si->data =3D xmalloc (si->size); si->data[0] =3D idx & 0xff; si->data[1] =3D idx >> 8; ! strcpy (si->data + 2, xlate (exp->name)); } break; case IDATA7: si->size =3D 4; ! si->data =3Dxmalloc (4); memset (si->data, 0, si->size); rel =3D xmalloc (sizeof (arelent)); rpp =3D xmalloc (sizeof (arelent *) * 2); --- 2517,2535 ---- why it did that, and it does not match what I see in programs compiled with the MS tools. */ int idx =3D exp->hint; ! char const * internal_name =3D ! exp->internal_name ? exp->internal_name : xlate (exp->name); !=20 ! si->size =3D strlen (internal_name) + 3; si->data =3D xmalloc (si->size); si->data[0] =3D idx & 0xff; si->data[1] =3D idx >> 8; ! strcpy (si->data + 2, internal_name); } break; case IDATA7: si->size =3D 4; ! si->data =3D xmalloc (4); memset (si->data, 0, si->size); rel =3D xmalloc (sizeof (arelent)); rpp =3D xmalloc (sizeof (arelent *) * 2); *************** |
From: Danny S. <dan...@cl...> - 2004-09-05 00:28:37
|
----- Original Message ----- From: "Hartmut Birr" Hi, I think that line 903 in dlltool.c is not the problem. If I print the import libraries, I see a difference in the IDATA6 section. I think that the problem is in dlltool.c at line 2520-2527. - Hartmut Sure, the new test for non-null exp->internal_name is bogus since def_exports sets internal_name to name by default. Anyway, its fixed now. I'll upload new RC tonight (NZ time) Danny |
From: Carlo W. <ca...@al...> - 2004-09-05 12:10:45
|
On Sun, Sep 05, 2004 at 12:23:15PM +1200, Danny Smith wrote: > > ----- Original Message ----- > From: "Hartmut Birr" > Hi, > > I think that line 903 in dlltool.c is not the problem. If I print the > import > libraries, I see a difference in the IDATA6 section. I think that the > problem is in dlltool.c at line 2520-2527. > > - Hartmut > > > Sure, the new test for non-null exp->internal_name is bogus since > def_exports sets internal_name to name by default. > > Anyway, its fixed now. I'll upload new RC tonight (NZ time) Sorry but it is not fixed, you just reinstalled the previous, broken behaviour, by removing my patch. I am bit agitated that you haven't even waited for my comments on this, being the original author of this binutils patch, before reverting it and calling it "fixed". I hope you see the indirect insult towards my address in that :/. My patch is needed to correctly address aliases in .def files and it is *especially* needed for mingw because the win32 platform uses the __stdcall calling convention that prepends an underscore and appends the @<n> part to the function name, while gcc does not prepend that underscore (just adds the @<n> part). As a result, it is possible to have a mismatch between what an application tries to resolve (looks up in the import library) and the internal names used in the .dll. For example, a native .dll can define the internal function _func@8 as a result of using __stdcall. But the same header containing the prototype of 'func' (using the __stdcall qualifier (ie by means of the WINAPI macro)) will cause gcc to generate the symbol 'func@8', without the underscore. In this case one could use the dlltool option '--add-underscore' together with symbols *without* underscore in the .def file. Then the internal name will be equal to the EXPORTED name(s) plus the underscore. But, what if there are other symbols being exported that are NOT __stdcall's? That do not need underscores? In that case you need to use a .def file with aliases. For example, if the .dll contains another function that is NOT a __stdcall function and has the name 'foobar' then the .def file would need to contain: foobar func@8 = _func@8 Using '--add-underscore' won't help here because the .dll defines 'foobar' and not '_foobar'! You NEED the aliases. The old dlltool, without the latest patch, ignores the aliases (everything behind the '=') completely, making it impossible to address this case. If you want the old behaviour then you can simply remove all aliases from the .def file before processing it with dlltool. By removing the patch you cause dlltool to *always* ignore all aliases in .def files. But sometimes those aliases are the only way to create a working import library and that is impossible with your release now. To summarize - you should use the original dlltool as released by binutils and instead fix broken .def files that specify incorrect aliases. -- Carlo Wood <ca...@al...> |
From: Hartmut B. <har...@gm...> - 2004-09-05 14:53:31
|
> -----Original Message----- > From: min...@li...=20 > [mailto:min...@li...] On Behalf Of=20 > Carlo Wood > Sent: Sunday, September 05, 2004 2:10 PM > To: min...@li... > Subject: Re: [Mingw-users] dlltool.c (was: Announcement:=20 > Binutils-2.15.91-20040902 1 Release candidate) >=20 >=20 >=20 > If you want the old behaviour then you can simply remove all > aliases from the .def file before processing it with dlltool. > By removing the patch you cause dlltool to *always* ignore all > aliases in .def files. But sometimes those aliases are the only > way to create a working import library and that is impossible > with your release now. >=20 > To summarize - you should use the original dlltool as released > by binutils and instead fix broken .def files that specify > incorrect aliases. >=20 > --=20 > Carlo Wood <ca...@al...> >=20 If I understand your answer correctly, you are the opinion that in the = def files is somewhat wrong. There exist two (three with cdecl calling convention) types of functions:=20 KIRQL __attribute__ ((fastcall)) KfRaiseIrql (IN KIRQL NewIrql); void __attribute__ ((stdcall)) KeRaiseIrql (IN KIRQL NewIrql, OUT = PKIRQL oldIrql); I need a way to bild an import library for importing this function by = other dll's and I must build the dll which exports this functions. Currently = there exist two def files: For building the import library (hal.def): LIBRARY hal.dll EXPORTS ... KeRaiseIrql@8 @KfRaiseIrql@4 ... dlltool --as=3Das --dllname hal.dll \ --def ./../hal/hal.def \ --output-lib ./hal.a \ --kill-at For building the dll (hal.dll) which exports this functions (hal.edf): LIBRARY hal.dll EXPORTS ... KeRaiseIrql=3DKeRaiseIrql@8 KfRaiseIrql=3D@KfRaiseIrql@4 ... gcc -Wl,--base-file,base.tmp \ -Wl,--entry,_DriverEntry@8 \ -g \ -nostartfiles -nostdlib \ -o junk.tmp \ ./halx86up.coff hal.stripped.o ../../dk/nkm/lib/ntoskrnl.a ../../tools/rdel junk.tmp dlltool --as=3Das --dllname hal.dll \ --base-file base.tmp \ --output-exp temp.exp --def ./../hal/hal.edf ../../tools/rdel base.tmp gcc -g \ -Wl,--subsystem,native \ -Wl,--image-base,0x10000 \ -Wl,--file-alignment,0x1000 \ -Wl,--section-alignment,0x1000 \ -Wl,--entry,_DriverEntry@8 \ -Wl,temp.exp \ -mdll -nostartfiles -nostdlib \ -o hal.dll \ ./halx86up.coff hal.stripped.o ../../dk/nkm/lib/ntoskrnl.a ../../tools/rdel temp.exp hal.stripped.o Building the dll (ntoskrnl.exe) which imports from hal.dll: gcc \ -Wl,-T,ntoskrnl.lnk \ -nostartfiles \ -nostdlib \ -mdll \ -o junk.tmp \ -Wl,--subsystem,native \ -Wl,--image-base,0xc0000000 \ -Wl,--file-alignment,0x1000 \ -Wl,--section-alignment,0x1000 \ -Wl,--entry,_NtProcessStartup \ -Wl,--base-file,base.tmp \ ntoskrnl.all.o -lgcc \ ../dk/nkm/lib/hal.a \ ../dk/w32/lib/rtl.a \ ../dk/w32/lib/string.a \ ../dk/w32/lib/rosrtl.a \ ../dk/w32/lib/pseh.a ../tools/rdel junk.tmp dlltool --as=3Das \ --dllname ntoskrnl.exe \ --base-file base.tmp \ --output-exp temp.exp \ --def ntoskrnl.edf \ --kill-at ../tools/rdel base.tmp gcc \ -Wl,-T,ntoskrnl.lnk -Wl,-s\ -nostartfiles \ -nostdlib \ -mdll \ -o ntoskrnl.exe \ -Wl,--subsystem,native \ -Wl,--image-base,0xc0000000 \ -Wl,--file-alignment,0x1000 \ -Wl,--section-alignment,0x1000 \ -Wl,--entry,_NtProcessStartup \ -Wl,temp.exp \ ntoskrnl.all.o -lgcc \ ../dk/nkm/lib/hal.a \ ../dk/w32/lib/rtl.a \ ../dk/w32/lib/string.a \ ../dk/w32/lib/rosrtl.a \ ../dk/w32/lib/pseh.a ../tools/rdel temp.exp Up to dlltool 2.15.90 the imported and exported names were always KeRaiseIrql and KfRaiseIrql. Since dlltools 2.15.91 the exported names = are the same and the imported names are KeRaiseIrql@8 and @KfRaiseIrql@4. = What must I change to get the correct names?=20 - Hartmut=20 |
From: Carlo W. <ca...@al...> - 2004-09-05 17:29:09
|
On Sun, Sep 05, 2004 at 04:53:13PM +0200, Hartmut Birr wrote: > LIBRARY hal.dll > EXPORTS > ... > KeRaiseIrql=KeRaiseIrql@8 > KfRaiseIrql=@KfRaiseIrql@4 [...] > Up to dlltool 2.15.90 the imported and exported names were always > KeRaiseIrql and KfRaiseIrql. Since dlltools 2.15.91 the exported names are > the same and the imported names are KeRaiseIrql@8 and @KfRaiseIrql@4. What > must I change to get the correct names? I am sorry if I did not explain this clearly enough in my previous post: <Carlo> [...] The old <Carlo> dlltool, without the latest patch, ignores the aliases (everything <Carlo> behind the '=') completely, making it impossible to address this <Carlo> case. <Carlo>If you want the old behaviour then you can simply remove all <Carlo>aliases from the .def file before processing it with dlltool. Let me try again; when you have the following two lines in the .def file: KeRaiseIrql=KeRaiseIrql@8 KfRaiseIrql=@KfRaiseIrql@4 then the old behaviour is to use the names left of the equal signs as exported names AND as 'imported' names (whatever is put in the idata$6 section. That section contains the names that are looked up in the .dll file at runtime when a function is called for the first time). The new, and correct behaviour is to use the names at the RIGHT of the equal signs as 'imported' names for the exported names on the left. You can therefore very easily get the old behaviour back by removing the names on the right. Change the .def file into: KeRaiseIrql KfRaiseIrql =========================================================== Here is a more general explanation of how things work. You can do the following: 1) Find out what the .dll exports (those are the symbols as looked up at runtime or what is used when dlopen-ing a .dll and looking up a symbol in it with dlsym) using the following command: link.exe -dump -exports hal.dll This gives for example: foo _bar _foobar@8 2) Find out what your application expects by compiling the object files (*.o or *.obj) and using 'nm' to see what are the Undefined symbols. For example, this shows that the application needs 0x000000 U _foo 0x000000 U bar@4 0x000000 U foobar@8 Then you will need an import library (which is just a normal archive (*.a on UNIX, *.lib on win32) that exists of stubs that exports functions that your application expects (the 'U' symbols aboove) and contains special sections with special data that the dynamic runtime linker on windows understands. If you already HAVE a .lib or .a import library then you can can see easily what it exports with 'nm', but not what it tries to call in the .dll because those names are hidden in the idata$6 section as normal data (so, you have to use the same tool that you used before to examine the idata$6 contents). [For archiving purposes: note that an import library on mingw, although just being a normal archive, should end in ".dll.a" not only because that is a convention, but also in order to allow libtool to recognise it as _import_ library (otherwise libtool will ignore it as a 'static' archive library and refuse to link with it when you are creating another .dll). Thus: .lib and .a are both normal archives but the extension .dll.a is needed in order to get libtool to work. (and the .a is needed to get gcc to link with: if you use -lfoo it will look for libfoo.a and libfoo.dll.a - both names would work therefore; a foo.dll therefore corresponds with the (mingw) import library name libfoo.dll.a)]. In order to create such an import library you then need to create a .def file with the lines: _foo = foo bar@4 = _bar foobar@8 = _foobar@8 where on the left are the exported names and on the right the internal 'imported' names. -- Carlo Wood <ca...@al...> |
From: Aaron W. L. <aar...@aa...> - 2004-09-05 19:26:39
|
Carlo Wood wrote: > then the old behaviour is to use the names left of the > equal signs as exported names AND as 'imported' names > (whatever is put in the idata$6 section. That section > contains the names that are looked up in the .dll file > at runtime when a function is called for the first time). > > The new, and correct behaviour is to use the names at > the RIGHT of the equal signs as 'imported' names for > the exported names on the left. I'm still slightly confused about the interaction between what your patch does, and what is described in the bug report at <http://sources.redhat.com/bugzilla/show_bug.cgi?id=351>. In any case, I just tested a version of vanilla binutils right after your patch against MS link /lib, 7.10.3052 specifically, and it does not match your behavior. Do you have some documentation that states it should be otherwise? I beleive that your patch is similar to my flawed patch here <http://sources.redhat.com/ml/binutils/2004-06/msg00514.html>, where I made a similar mistake about the meaning of the internal name. As near as I can tell, the internal name should be completely ignored by dlltool for purposes of generating import libraries. There are three symbol names of importance: 1) The name of the symbol in the source code of the library itself. 2) The name of the symbol that is exported from the DLL. 3) The name of the symbol that is used in the source code that uses the library. The internal name is #1. There is no way in the DEF file format to have #2 as something different from #3, which is partly why I added the --ext-prefix-alias option: <http://sources.redhat.com/ml/binutils/2004-07/msg00130.html>. Is this consistant with what you have in mind? Sorry for not commenting earlier. I didn't realize that not all binutils patches were posted to the binutils list. I think I need to start watching binutils Bugzilla. Aaron W. LaFramboise |
From: Carlo W. <ca...@al...> - 2004-09-05 23:33:27
|
On Sun, Sep 05, 2004 at 02:26:17PM -0500, Aaron W. LaFramboise wrote: > I'm still slightly confused about the interaction between what your > patch does, and what is described in the bug report at > <http://sources.redhat.com/bugzilla/show_bug.cgi?id=351>. > > In any case, I just tested a version of vanilla binutils right after > your patch against MS link /lib, 7.10.3052 specifically, and it does not > match your behavior. Do you have some documentation that states it > should be otherwise? I am afraid not. Let me start with stating that I could be wrong. What I did was debug the whole thing till assembly level, mainly leaning on http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndebug/html/msdn_peeringpe.asp?frame=true&hidetoc=true which is the only documentation with a little depth that I could find. Next to that, I have experimented a lot with generating import libraries (changing results with a hex editor and observing the effects) until I was convinced that I finally understood how .dll files and the dynamic linking worked. I created a test case that goes like this: $ make -f Makefile.na *** Creating msvc.exp, msvc.lib and msvc.dll files using cl cl -LDd msvc.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. msvc.c Microsoft (R) Incremental Linker Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. /out:msvc.dll /dll /implib:msvc.lib msvc.obj Creating library msvc.lib and object msvc.exp rm -f msvc.obj *** Creating msvc.def from msvc.dll using pexports pexports msvc.dll | sed -e 's/^_\([[:alnum:]_@]*\)\(.*\)$/\1 = _\1\2/' > msvc.def *** Creating libmsvc.dll.a from msvc.def using dlltool ../dlltool/dlltool -S as -d msvc.def -l libmsvc.dll.a debug: def_exports(name = msvclibstdcall@4, internal_name = _msvclibstdcall@4, ordinal = -1) debug: def_exports(name = msvclibfunc, internal_name = (null), ordinal = -1) *** Creating mingw.dll, libmingw.dll.a and mingw.def files using gcc gcc -shared -o mingw.dll mingw.c -Wl,--output-def,mingw.def,--out-implib,libmingw.dll.a Creating library file: libmingw.dll.a *** Creating mingw2.dll, libmingw2.dll.a and mingw2.def files using gcc gcc -shared -o mingw2.dll mingw2.c -Wl,--output-def,mingw2.def,--out-implib,libmingw2.dll.a -L. -lmsvc -lmingw Creating library file: libmingw2.dll.a * Creating testmain.exe: gcc -o testmain testmain.c * Running test: Success! OK I'd like to compare the behaviour of MS link /lib with dlltool too, but what I get when I try to use 'link' instead of dlltool there is this: [...] *** Creating libmsvc.dll.a from msvc.def using dlltool #../dlltool/dlltool -S as -d msvc.def -l libmsvc.dll.a COMMENTED OUT link -lib -def:msvc.def -out:libmsvc.dll.a AND REPLACED WITH THIS Microsoft (R) Library Manager Version 7.10.3077 Copyright (C) Microsoft Corporation. All rights reserved. LINK : warning LNK4068: /MACHINE not specified; defaulting to X86 Creating library libmsvc.dll.a and object libmsvc.dll.exp *** Creating mingw.dll, libmingw.dll.a and mingw.def files using gcc gcc -shared -o mingw.dll mingw.c -Wl,--output-def,mingw.def,--out-implib,libmingw.dll.a Creating library file: libmingw.dll.a *** Creating mingw2.dll, libmingw2.dll.a and mingw2.def files using gcc gcc -shared -o mingw2.dll mingw2.c -Wl,--output-def,mingw2.def,--out-implib,libmingw2.dll.a -L. -lmsvc -lmingw Cannot export .idata$4: symbol not found Cannot export .idata$5: symbol not found Cannot export .idata$6: symbol not found Cannot export .text: symbol not found Cannot export msvc_NULL_THUNK_DATA: symbol not found Creating library file: libmingw2.dll.a make: *** [mingw2.dll] Error 1 Can you tell me how to use MS link to do what dlltool can do then? > I beleive that your patch is similar to my flawed patch here > <http://sources.redhat.com/ml/binutils/2004-06/msg00514.html>, where I > made a similar mistake about the meaning of the internal name. I don't see the similarity yet ... you changed the __imp__ names. But again, I might be wrong and you might be right. I propose to continue this discussion until we have a clear documentation of what the meaning things in the .def files are and where/how exactly they are being used during all the link processes. > As near as I can tell, the internal name should be completely ignored by > dlltool for purposes of generating import libraries. Two remarks: - Is that documented somewhere? Where? - I state that if that is true, then it is impossible to generate an import library for mingw (it would not be a problem for native windows) with dlltool when it contains both stdcall's and non-stdcalls. If my statement is true - then in the very least we will need an additional option for dlltool to address the problem that gcc does not add an underscore to stdcall functions. > There are three > symbol names of importance: > 1) The name of the symbol in the source code of the library itself. Do you mean without decoration? Or do you refer to the already decorated name as defined in the .dll? > 2) The name of the symbol that is exported from the DLL. This is what we are calling 'internal name' all the time, correct? > 3) The name of the symbol that is used in the source code that uses the > library. With or without decoration? The name that is used in the SOURCE code is obviously without decoration; but that is of little interest for our discussion. Therefore I assume you already mean the name including decoration. A better description would therefore be: The name of the symbol that is used in the object files of the final application (that that final application can be another dll is too confusing to mention all the time; I think we can concentrate on just a .exe - do you agree?). > The internal name is #1. Ok, so already with decoration then. Example would be: _foobar@8 When it was compiled with cl.exe (which adds an underscore for stdcall's). At this point I lost you though. Because if #1 is the internal name, then what is #2? > There is no way in the DEF file format to have > #2 as something different from #3, which is partly why I added the > --ext-prefix-alias option: > <http://sources.redhat.com/ml/binutils/2004-07/msg00130.html>. > > Is this consistant with what you have in mind? I cannot comment on this, as I do not understand what exactly #1, #2 and #3 are. Note that nowhere in my previous investigations and tests I ran into the meaning of the __imp__name symbols. Perhaps that is what you should explain to me then :/ > Sorry for not commenting earlier. I didn't realize that not all > binutils patches were posted to the binutils list. I think I need to > start watching binutils Bugzilla. > > Aaron W. LaFramboise Thanks for helping me understand this in more detail. If my previous path is wrong, then I'd like to write another path that adds an option to dlltool to somehow achieve what I wanted: to fix the problem that occurs as a result of gcc not adding the underscore for stdcalls while cl.exe *is* doing that. After full analysis and understanding the Everything(tm), I am sure we can solve that problem too, and then correctly. -- Carlo Wood <ca...@al...> |
From: Aaron W. L. <aar...@aa...> - 2004-09-06 00:39:01
|
Carlo Wood wrote: > I'd like to compare the behaviour of MS link /lib with dlltool > too, but what I get when I try to use 'link' instead of dlltool > there is this: > > [...] > *** Creating libmsvc.dll.a from msvc.def using dlltool > #../dlltool/dlltool -S as -d msvc.def -l libmsvc.dll.a COMMENTED OUT > link -lib -def:msvc.def -out:libmsvc.dll.a AND REPLACED WITH THIS > Microsoft (R) Library Manager Version 7.10.3077 > Copyright (C) Microsoft Corporation. All rights reserved. > > LINK : warning LNK4068: /MACHINE not specified; defaulting to X86 > Creating library libmsvc.dll.a and object libmsvc.dll.exp > *** Creating mingw.dll, libmingw.dll.a and mingw.def files using gcc > gcc -shared -o mingw.dll mingw.c -Wl,--output-def,mingw.def,--out-implib,libmingw.dll.a > Creating library file: libmingw.dll.a > *** Creating mingw2.dll, libmingw2.dll.a and mingw2.def files using gcc > gcc -shared -o mingw2.dll mingw2.c -Wl,--output-def,mingw2.def,--out-implib,libmingw2.dll.a -L. -lmsvc -lmingw > Cannot export .idata$4: symbol not found > Cannot export .idata$5: symbol not found > Cannot export .idata$6: symbol not found > Cannot export .text: symbol not found > Cannot export msvc_NULL_THUNK_DATA: symbol not found > Creating library file: libmingw2.dll.a > make: *** [mingw2.dll] Error 1 > > Can you tell me how to use MS link to do what dlltool can do then? I'm not sure whats happening here. To test functionality, I just created a .def file with an arbitrary symbol and generated two import libraries from it: one with link /lib, and one with dlltool. I then created an object with a dummy main() that referenced the symbol in the import library, linked it with the import library, and examined the resulting executable's export section. With MS tools, internal name has no affect in this configuration. >>I beleive that your patch is similar to my flawed patch here >><http://sources.redhat.com/ml/binutils/2004-06/msg00514.html>, where I >>made a similar mistake about the meaning of the internal name. > > I don't see the similarity yet ... you changed the __imp__ names. > But again, I might be wrong and you might be right. I propose > to continue this discussion until we have a clear documentation > of what the meaning things in the .def files are and where/how > exactly they are being used during all the link processes. My flawed patch changed both the imp and non-imp names. The imp names are for dllimport. Any renaming or aliasing would have to change both. >>As near as I can tell, the internal name should be completely ignored by >>dlltool for purposes of generating import libraries. > > Two remarks: - Is that documented somewhere? Where? > - I state that if that is true, then it is impossible > to generate an import library for mingw (it would > not be a problem for native windows) with dlltool when > it contains both stdcall's and non-stdcalls. The meaning of the internal name is documented, in a somewhat ambiguous fashion, in the LINK and LIB documentation, availible on MSDN. At one time, and still in some circles, the relationships between imports, exports, EXPs, DLLs, and DEFs were well-understood. However, the basic machinery is quite old, and much is obsolete, and as the science has advanced, things have come to appear somewhat backwards and unintuitive, particularly coming from a modern implementation such as Linux. (In no way do I mean that such modern implementations are inherently better, though.) mingwrt .def and w32api .def files do not use the internal name aliases. > Do you mean without decoration? Or do you refer to the already decorated > name as defined in the .dll? Decoration is a separate issue. In my last post, I was avoiding the issue of decoration entirely. It is, in fact, my perception that the internal name feature was not even designed to circumvent decoration, as many people seem to think it is. Even when it is used to do so, this is only on the DLL implementation side, not the DLL user side. >>2) The name of the symbol that is exported from the DLL. > > This is what we are calling 'internal name' all the time, correct? When I say 'internal name,' I mean the symbol name on the right hand side of the '=' in the EXPORTS section of a .def file, which corresponds to #1 above, the actual name of the symbol in the DLL implementation (which, in the case of stdcall, will be decorated). > >>3) The name of the symbol that is used in the source code that uses the >>library. > > With or without decoration? The name that is used in the SOURCE code > is obviously without decoration; but that is of little interest > for our discussion. Therefore I assume you already mean the name > including decoration. A better description would therefore be: > The name of the symbol that is used in the object files of the > final application (that that final application can be another dll > is too confusing to mention all the time; I think we can concentrate > on just a .exe - do you agree?). I meant the name of the symbol in the .o files generated from the source code. These will be decorated, in the case of stdcall. >>The internal name is #1. > > > Ok, so already with decoration then. > Example would be: _foobar@8 > When it was compiled with cl.exe (which adds an underscore for stdcall's). > > At this point I lost you though. Because if #1 is the internal name, > then what is #2? #2 is what appears to the immediate left of the '=' in the EXPORTS in the .def. It is an unfortunate design decision that many Microsoft libraries choose to discard stdcall decorations at this step. I have no idea why this was done, as it defeats the entire purpose of stdcall decoration. In general, both #1 and #3 will be stdcall decorated, so its a little strange that #2 randomly isn't. The usual way that this is worked around--by Microsoft's tools, GNU binutils, and probably others--is adding extra logic to the linking machinery to do some 'fuzzy linking' of non-decorated symbols to decorated symbols. In binutils, both ld and dlltool can do this, depending on exactly whats going on. As a practical matter, I am opposed to making any sort of change to dlltool that causes it to behave differently from either the generally accepted view of how it should work, the MS documentation of link/lib and DEF, or the actual functioning of MS link/lib. I think that means the last two patches should be reverted and, if necessary, replaced with something that addresses whatever you are trying to do. What are you trying to do, by the way? Aaron W. LaFramboise |
From: Carlo W. <ca...@al...> - 2004-09-06 12:00:03
|
On Sun, Sep 05, 2004 at 07:39:34PM -0500, Aaron W. LaFramboise wrote: > I'm not sure whats happening here. :/ > To test functionality, I just created a .def file with an arbitrary > symbol and generated two import libraries from it: one with link /lib, > and one with dlltool. I then created an object with a dummy main() that > referenced the symbol in the import library, linked it with the import > library, and examined the resulting executable's export section. With > MS tools, internal name has no affect in this configuration. Like Wu Yongwei said, also link /lib is ignoring the internal name. But is that correct? More important observation is however that when using MS tools it makes no difference that it is ignored! There is no NEED to specify an alias there because MS tools are consistent in that they add an underscore or not. The problem occurs when you want to link a gcc compiled application with a MS tools compiled .dll and have to generate the .dll.a from that MS tools compiled .dll. Then you need the aliases. Therefore, the functionality of dlltool is more demanding than that of MS tools: dlltool has to address this more complex case. > >>I beleive that your patch is similar to my flawed patch here > >><http://sources.redhat.com/ml/binutils/2004-06/msg00514.html>, where I > >>made a similar mistake about the meaning of the internal name. > > > > I don't see the similarity yet ... you changed the __imp__ names. > > But again, I might be wrong and you might be right. I propose > > to continue this discussion until we have a clear documentation > > of what the meaning things in the .def files are and where/how > > exactly they are being used during all the link processes. > > My flawed patch changed both the imp and non-imp names. The imp names > are for dllimport. Any renaming or aliasing would have to change both. dllimport? Is that a tool? Sorry, but I am UNIX guy - 'import' doesn't really tell me much. I understand 'exported' symbols in the UNIX meaning (whatever 'nm' shows with an uppercase (T for example)) and I figured out that a so called "import library" exports functions that are merely just little stubs that jmp to the real start of the function, in the .dll file. This jmp is changed to address the load address of the library or something like that, and that address is found by looking up the symbol in the .dll that is mentioned in the .idata$6 section of the import library. > >>As near as I can tell, the internal name should be completely ignored by > >>dlltool for purposes of generating import libraries. > > > > Two remarks: - Is that documented somewhere? Where? > > - I state that if that is true, then it is impossible > > to generate an import library for mingw (it would > > not be a problem for native windows) with dlltool when > > it contains both stdcall's and non-stdcalls. > > The meaning of the internal name is documented, in a somewhat ambiguous > fashion, in the LINK and LIB documentation, availible on MSDN. > > At one time, and still in some circles, the relationships between > imports, exports, EXPs, DLLs, and DEFs were well-understood. However, > the basic machinery is quite old, and much is obsolete, and as the > science has advanced, things have come to appear somewhat backwards and > unintuitive, particularly coming from a modern implementation such as > Linux. (In no way do I mean that such modern implementations are > inherently better, though.) > > mingwrt .def and w32api .def files do not use the internal name aliases. Then my dlltool path should have no influence. > > Do you mean without decoration? Or do you refer to the already decorated > > name as defined in the .dll? > > Decoration is a separate issue. In my last post, I was avoiding the > issue of decoration entirely. It is, in fact, my perception that the > internal name feature was not even designed to circumvent decoration, as > many people seem to think it is. Even when it is used to do so, this is > only on the DLL implementation side, not the DLL user side. The patch only changes the DLL side (it allows one to specify the internal name). Also, it is *needed* in relationship to decorations because gcc and MS tools handle stdcalls differently. The kludgy dlltool options that attempt to fix this by translating ALL symbols are not enough when not ALL symbols have to be treated the same - as is the case when some symbols are stdcall's and others are not, in the same dll. > >>2) The name of the symbol that is exported from the DLL. > > > > This is what we are calling 'internal name' all the time, correct? > > When I say 'internal name,' I mean the symbol name on the right hand > side of the '=' in the EXPORTS section of a .def file, Good, me too. > which corresponds > to #1 above, the actual name of the symbol in the DLL implementation > (which, in the case of stdcall, will be decorated). Ok. Then so far my patch does the Right Thing(tm). > >>3) The name of the symbol that is used in the source code that uses the > >>library. > > > > With or without decoration? The name that is used in the SOURCE code > > is obviously without decoration; but that is of little interest > > for our discussion. Therefore I assume you already mean the name > > including decoration. A better description would therefore be: > > The name of the symbol that is used in the object files of the > > final application (that that final application can be another dll > > is too confusing to mention all the time; I think we can concentrate > > on just a .exe - do you agree?). > > I meant the name of the symbol in the .o files generated from the source > code. These will be decorated, in the case of stdcall. ... which correspond to the left hand side of the '=' in the EXPORTS section of a .def file. Right? > >>The internal name is #1. > > > > > > Ok, so already with decoration then. > > Example would be: _foobar@8 > > When it was compiled with cl.exe (which adds an underscore for stdcall's). > > > > At this point I lost you though. Because if #1 is the internal name, > > then what is #2? > > #2 is what appears to the immediate left of the '=' in the EXPORTS in > the .def. It is an unfortunate design decision that many Microsoft > libraries choose to discard stdcall decorations at this step. I have no > idea why this was done, as it defeats the entire purpose of stdcall > decoration. In general, both #1 and #3 will be stdcall decorated, so > its a little strange that #2 randomly isn't. You lost me again. Clearly you cannot define #1, #2 or #3 by merely refering to what is in the .def file :/. I'd like to understand what the names in the .def file SHOULD be - so they must hould be defined last. "the name of the symbol in the .o files generated from the source code." is #3 you say. Then what is #2 ? Right now I see absolutely no difference between #2 and #3. There seem to be only two different names. > The usual way that this is worked around--by Microsoft's tools, GNU > binutils, and probably others--is adding extra logic to the linking > machinery to do some 'fuzzy linking' of non-decorated symbols to > decorated symbols. In binutils, both ld and dlltool can do this, > depending on exactly whats going on. > > As a practical matter, I am opposed to making any sort of change to > dlltool that causes it to behave differently from either the generally > accepted view of how it should work, the MS documentation of link/lib > and DEF, or the actual functioning of MS link/lib. I think that means > the last two patches should be reverted and, if necessary, replaced with > something that addresses whatever you are trying to do. > > What are you trying to do, by the way? My initial need was to generate a mingw import library that can be used by gcc (.dll.a), when that is missing for a MS .dll, in such a way that it can be used to create another DLL that depends on both, a libtool generated .dll and that MS (cl compiled/linked) .dll. The existing tools then turn out not to address the case where a library contains both, stdcall functions as well as non-stdcall functions at the same time. My current test case is rather complex: it provides both, a custom way to compile things as well as automake/autoconf/libtool way to do the same (I was trying to make a test case to prove that libtool was missing something; but that turned out not to be the case), it involves three libraries and an executable that uses libltdl to dynamically load a .dll that is using the other two libraries. I therefore will try to strip this test case down to a smaller case and then post it here. -- Carlo Wood <ca...@al...> |
From: Aaron W. L. <aar...@aa...> - 2004-09-06 20:23:26
|
Carlo Wood wrote: > Like Wu Yongwei said, also link /lib is ignoring the internal name. > But is that correct? More important observation is however that when > using MS tools it makes no difference that it is ignored! There is > no NEED to specify an alias there because MS tools are consistent in > that they add an underscore or not. The problem occurs when you want > to link a gcc compiled application with a MS tools compiled .dll and > have to generate the .dll.a from that MS tools compiled .dll. > Then you need the aliases. Therefore, the functionality of dlltool > is more demanding than that of MS tools: dlltool has to address this > more complex case. Yes, the internal name has no meaning when generating import libraries. It does have a meaning though, and MS tools (and GNU tools as far as I know) correctly recognize this meaning when linking. See below. >>>>I beleive that your patch is similar to my flawed patch here >>>><http://sources.redhat.com/ml/binutils/2004-06/msg00514.html>, where I >>>>made a similar mistake about the meaning of the internal name. >>> >>>I don't see the similarity yet ... you changed the __imp__ names. >>>But again, I might be wrong and you might be right. I propose >>>to continue this discussion until we have a clear documentation >>>of what the meaning things in the .def files are and where/how >>>exactly they are being used during all the link processes. >> >>My flawed patch changed both the imp and non-imp names. The imp names >>are for dllimport. Any renaming or aliasing would have to change both. > > dllimport? Is that a tool? dllimport is the usual and preferred way to export symbols from a library. It is similar to the recent visibility additions to ELF. Most projects use dllimport and dllexport rather than screwing around with .def files. The imp symbols refer to a separate thunk in the DLL used to implement this functionality. > Sorry, but I am UNIX guy - 'import' doesn't really tell me much. > > I understand 'exported' symbols in the UNIX meaning (whatever 'nm' > shows with an uppercase (T for example)) and I figured out that > a so called "import library" exports functions that are merely > just little stubs that jmp to the real start of the function, in > the .dll file. This jmp is changed to address the load address > of the library or something like that, and that address is found > by looking up the symbol in the .dll that is mentioned in the > .idata$6 section of the import library. As in ELF, there are two sorts of symbols we care about: normal symbols, and dynamic symbols. nm ordinarily only shows the normal symbols, which are only useful for debugging once we have linked an executable or dynamic library. I think theres an option to nm to let it view ELF dynamic symbols, but for PE, you need to use objdump. >>mingwrt .def and w32api .def files do not use the internal name aliases. > > Then my dlltool path should have no influence. Your patch will have an influence on .def files that correctly use internal names. >>>Do you mean without decoration? Or do you refer to the already decorated >>>name as defined in the .dll? >> >>Decoration is a separate issue. In my last post, I was avoiding the >>issue of decoration entirely. It is, in fact, my perception that the >>internal name feature was not even designed to circumvent decoration, as >>many people seem to think it is. Even when it is used to do so, this is >>only on the DLL implementation side, not the DLL user side. > > The patch only changes the DLL side (it allows one to specify the internal name). > Also, it is *needed* in relationship to decorations because gcc and MS tools > handle stdcalls differently. The kludgy dlltool options that attempt to fix > this by translating ALL symbols are not enough when not ALL symbols have to > be treated the same - as is the case when some symbols are stdcall's and others > are not, in the same dll. I am actually slightly confused with regards to this underscore you're having problems with. Nearly all symbols we care about have leading underscores, including cdecl, and including the symbol names that dlltool generates (the only exception that I am familiar with are MSVC C++ functions, which begin with a '?' and have special handling in binutils). Are you sure your .def file is correct? >>>>2) The name of the symbol that is exported from the DLL. >>> >>>This is what we are calling 'internal name' all the time, correct? >> >>When I say 'internal name,' I mean the symbol name on the right hand >>side of the '=' in the EXPORTS section of a .def file, > > Good, me too. > > >>which corresponds >>to #1 above, the actual name of the symbol in the DLL implementation >>(which, in the case of stdcall, will be decorated). > > > Ok. Then so far my patch does the Right Thing(tm). No. The internal name has a well-defined meaning, that is correctly implemented by the Microsoft tools. The internal name refers to the name of the symbol within the implementation of the DLL, a name that is meaningless to users of the DLL. Your patch changes this meaning (but only within dlltool) to mean some other symbol name, which is incorrect. It will cause a well-formed .def file to create an incorrect import library. Specifically, it is incorrect for dlltool to do anything with the internal name, since neither of the two symbol names emitted by dlltool is the one referred to by the internal name. (That does not mean that internal name is generally ignored or unused. It is used, correctly, by some projects during DLL creation.) Any change, such as yours, which changes this, is inconsistant with correct operation, and incompatible with MS's tools. I think that you should revert your patch. > You lost me again. Clearly you cannot define #1, #2 or #3 by merely > refering to what is in the .def file :/. I'd like to understand what > the names in the .def file SHOULD be - so they must hould be defined last. dll_implementation.c: void joe() {} dll.def: bob=joe dll_user.c: extern void bob(); // ... 1) Internal name: this is _joe, in dll_implementation.o, and appearing to the RHS of the = in dll.def. 2) Exported name: this is _bob, in libdll.a, on the LHS of the = in dll.def. 3) User code name: this is also _bob, in dll_user.o, and unfortunately there is no way to make it different from #2 in the .def syntax. I had considered adding one after I realized my above patch was flawed, but decided against it as unnecessary. Instead, I added the --ext-prefix-alias option, which created another, source-compatible, way to do this. >>What are you trying to do, by the way? > > My initial need was to generate a mingw import library that can be > used by gcc (.dll.a), when that is missing for a MS .dll, in such a > way that it can be used to create another DLL that depends on both, > a libtool generated .dll and that MS (cl compiled/linked) .dll. > > The existing tools then turn out not to address the case where a > library contains both, stdcall functions as well as non-stdcall > functions at the same time. Yes they do. msvcrt.dll is a simple example. You might want to check out the source code in mingwrt, but its fairly straightfoward. Are you sure your .def file is correct? As I mentioned above, the underscore should not be a problem, as dlltool adds an ASM underscore to the object symbol names in the .def file. > My current test case is rather complex: it provides both, a custom > way to compile things as well as automake/autoconf/libtool way to > do the same (I was trying to make a test case to prove that libtool > was missing something; but that turned out not to be the case), > it involves three libraries and an executable that uses libltdl to > dynamically load a .dll that is using the other two libraries. If you're trying to simulate traditional ELF-style shared library semantics, I might recommend avoiding a .def file altogether if possible, as it does not add anything. Aaron W. LaFramboise |
From: Carlo W. <ca...@al...> - 2004-09-06 22:20:46
|
On Mon, Sep 06, 2004 at 03:22:56PM -0500, Aaron W. LaFramboise wrote: > > dllimport? Is that a tool? > > dllimport is the usual and preferred way to export symbols from a > library. It is similar to the recent visibility additions to ELF. Most > projects use dllimport and dllexport rather than screwing around with > .def files. The imp symbols refer to a separate thunk in the DLL used > to implement this functionality. Oh, THAT. You mean __declspec(dllimport). Yes, I am aware that that replaces the use of a .def file; except that I still won't be able to create the correct import library with an unpatch dlltool and/or without the aliases in the .def file :/. > No. The internal name has a well-defined meaning, that is correctly > implemented by the Microsoft tools. The internal name refers to the > name of the symbol within the implementation of the DLL, a name that is > meaningless to users of the DLL. Your patch changes this meaning (but > only within dlltool) to mean some other symbol name, which is incorrect. > It will cause a well-formed .def file to create an incorrect import > library. Specifically, it is incorrect for dlltool to do anything with > the internal name, since neither of the two symbol names emitted by > dlltool is the one referred to by the internal name. (That does not > mean that internal name is generally ignored or unused. It is used, > correctly, by some projects during DLL creation.) Any change, such as > yours, which changes this, is inconsistant with correct operation, and > incompatible with MS's tools. > > I think that you should revert your patch. Ok, I added this comment to http://sources.redhat.com/bugzilla/show_bug.cgi?id=351 > > You lost me again. Clearly you cannot define #1, #2 or #3 by merely > > refering to what is in the .def file :/. I'd like to understand what > > the names in the .def file SHOULD be - so they must hould be defined last. > > dll_implementation.c: void joe() {} > dll.def: bob=joe > dll_user.c: extern void bob(); // ... > I only see two names here, not three :/ The internal is 'joe' and the exported one is 'bob'. > 1) Internal name: this is _joe, in dll_implementation.o, and appearing > to the RHS of the = in dll.def. ok > 2) Exported name: this is _bob, in libdll.a, on the LHS of the = in dll.def. ok > 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. Sorry, but I still don't understand where you get the idea from that there are three _different_ names. 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 :/ 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 existing tools then turn out not to address the case where a > > library contains both, stdcall functions as well as non-stdcall > > functions at the same time. > > Yes they do. msvcrt.dll is a simple example. You might want to check > out the source code in mingwrt, but its fairly straightfoward. Are you > sure your .def file is correct? I think you should look at my smalltest.tar.gz. This is going nowhere :/ Same thing with Hartmut Birr, we exchanged a dozen mails without getting any understanding - then he posted a complete example in a tar - and it was immedeately clear (only costed me 3 minutes then). We need to use a Real Example too :/ [...snip...] -- Carlo Wood <ca...@al...> |
From: Aaron W. L. <aar...@aa...> - 2004-09-07 02:17:29
|
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 |
From: Carlo W. <ca...@al...> - 2004-09-07 10:10:30
|
On Mon, Sep 06, 2004 at 09:18:02PM -0500, Aaron W. LaFramboise wrote: > > 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. msvc.dll is generated by the Makefile. Just untar smalltest.tar.gz in a msys window and then run 'make': $ tar xzf smalltest.tar.gz $ make That 'make' will generate msvc.dll. Look at the Makefile, it contains this: msvc.dll msvc.lib msvc.exp: msvc.c msvc.h @echo "*** Creating msvc.exp, msvc.lib and msvc.dll files using cl" cl -LDd msvc.c You need to have 'cl' in your path therefore. -- Carlo Wood <ca...@al...> |
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 > |
From: Hartmut B. <har...@gm...> - 2004-09-05 19:38:22
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of > Carlo Wood > Sent: Sunday, September 05, 2004 7:29 PM > To: min...@li... > Subject: Re: [Mingw-users] dlltool.c (was: Announcement: > Binutils-2.15.91-20040902 1 Release candidate) > > > On Sun, Sep 05, 2004 at 04:53:13PM +0200, Hartmut Birr wrote: > > LIBRARY hal.dll > > EXPORTS > > ... > > KeRaiseIrql=KeRaiseIrql@8 > > KfRaiseIrql=@KfRaiseIrql@4 > [...] > > Up to dlltool 2.15.90 the imported and exported names were always > > KeRaiseIrql and KfRaiseIrql. Since dlltools 2.15.91 the > exported names are > > the same and the imported names are KeRaiseIrql@8 and > @KfRaiseIrql@4. What > > must I change to get the correct names? > > I am sorry if I did not explain this clearly enough in my > previous post: > > <Carlo> [...] The old > <Carlo> dlltool, without the latest patch, ignores the > aliases (everything > <Carlo> behind the '=') completely, making it impossible to > address this > <Carlo> case. > > <Carlo>If you want the old behaviour then you can simply remove all > <Carlo>aliases from the .def file before processing it with dlltool. > > Let me try again; when you have the following two lines in > the .def file: > > KeRaiseIrql=KeRaiseIrql@8 > KfRaiseIrql=@KfRaiseIrql@4 > > then the old behaviour is to use the names left of the > equal signs as exported names AND as 'imported' names > (whatever is put in the idata$6 section. That section > contains the names that are looked up in the .dll file > at runtime when a function is called for the first time). > > The new, and correct behaviour is to use the names at > the RIGHT of the equal signs as 'imported' names for > the exported names on the left. > > You can therefore very easily get the old behaviour back > by removing the names on the right. Change the .def > file into: > > KeRaiseIrql > KfRaiseIrql > I'm not sure whether I understand you or whether you understand me. Currently I will build a exe/dll/driver. I know the imported dlls and its specifications but I don't have the import library or the imported dll. The first step is to build the import libarary. The def file contains entries like this: KeRaiseIrql@8 @KfRaiseIrql@4 The second step is to build the exe/dll/driver. This file is linked against the import library. The exe/dll/driver _must_ import names like this: KeRaiseIrql KfRaiseIrql This has worked up to dlltool 2.15.90. Since dlltool 2.15.91 are the imported names: KeRaiseIrql@8 @KfRaiseIrql@4 This is wrong because the loader doesn't find this symbols in the imported dll. If I change the names in the def file for the import library to KeRaiseIrql KfRaiseIrql I get many link errors 'undefined reference to KeRaiseIrql@8'. What must I change in the build process to get the old and correct behaviour? - Hartmut |
From: Carlo W. <ca...@al...> - 2004-09-05 22:28:31
|
On Sun, Sep 05, 2004 at 09:38:03PM +0200, Hartmut Birr wrote: > > On Sun, Sep 05, 2004 at 04:53:13PM +0200, Hartmut Birr wrote: > > > LIBRARY hal.dll > > > EXPORTS > > > ... > > > KeRaiseIrql=KeRaiseIrql@8 > > > KfRaiseIrql=@KfRaiseIrql@4 [..SNIP..] > I'm not sure whether I understand you or whether you understand me. > Currently I will build a exe/dll/driver. I know the imported dlls and its > specifications but I don't have the import library or the imported dll. The > first step is to build the import libarary. The def file contains entries > like this: > > KeRaiseIrql@8 > @KfRaiseIrql@4 > > The second step is to build the exe/dll/driver. This file is linked against > the import library. The exe/dll/driver _must_ import names like this: > > KeRaiseIrql > KfRaiseIrql Now you are inconsistent. First you say that your .def file contains '=' (equal signs), and now you claim it doesn't. I have explained in detail what the effect of the patch is three times now. I have no idea how to make myself more clear. Let me just repeat that if your .def does not contain '=' signs like you quoted first/earlier - then the patch has no effect at all. However, it DOES have effect - so your .def file DOES contain '=' signs, apparently. As far as I know, a .def file is only used when you create an import library. I don't understand why you are talking about two different .def files. -- Carlo Wood <ca...@al...> |