From: Luke D. <cod...@ho...> - 2003-03-12 11:47:21
|
Danny, I was going to reply about your suggested patch but then I decided to let the binutils mailing list (which I am not subscribed to) deal with it, but I'm still not sure about it. >However, I admit that I not know enough about how this will affect parsing >of LIBRARY or NAME commands. With this patch, the special treatment of '.' >in opt_name appears to be redundant. > >My tests with LIBRARY or NAME commands in def files for windows targets >have succeeded with this patch. What am I missing? I agree that this change would remove the need for opt_name, so I think that the redundant rules should be removed because otherwise the parser becomes confusing. However, I believe that the patch breaks the handling of the "IMPORTS" section, but I wasn't even aware of such a section until now so I'm not sure of its purpose. I also haven't found any useful MSDN documentation on this section except a little about 16-bit apps. Here are the rules: impline: ID '=' ID '.' ID '.' ID { def_import ($1, $3, $5, $7, -1); } | ID '=' ID '.' ID '.' NUMBER { def_import ($1, $3, $5, 0, $7); } | ID '=' ID '.' ID { def_import ($1, $3, 0, $5, -1); } | ID '=' ID '.' NUMBER { def_import ($1, $3, 0, 0, $5); } | ID '.' ID '.' ID { def_import ( 0, $1, $3, $5, -1); } | ID '.' ID { def_import ( 0, $1, 0, $3, -1); } ; The def_import() function does just concatenate the module name and the DLL's file extension in the first two cases, but the patch will prevent the parser from distinguishing the function name (the last ID) from the DLL name. Some possible solutions (instead of the patch): 1. Define a "dotted_name" rule that parses an ID followed by any number of dots and IDs, then concatenates them. The dotted_name would replace ID in only "expline" and "opt_equal_name". 2. Use a "lexical tie-in" to temporarily set a flag in the parser that tells the lexer to treat '.' as part of an ID. 3. Insert quotes around the param of the -export directive in def_file_add_directive(). This would handle dllimport and --export-all but in theory a problematic .def file might be specified manually on the command line. If the IMPORTS section doesn't need to be supported in binutils anyway then that would be easy, but if it does then I guess there should be a test case, if we can find an example of its use. Other sections like "SECTIONS" are probably obsolete too. BTW, MSVC 6 generates something like this for an unnamed namespace, and processes it like any other export: ?foo@?%C:\devl\test\dlltest\dlltest.cpp42368689@@YAXXZ Luke _________________________________________________________________ MSN Instant Messenger now available on Australian mobile phones. Go to http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp |
From: Danny S. <dan...@cl...> - 2003-03-12 19:48:18
|
Thanks Luke The patch was approved and committed, so I guess we do need a testcase for the IMPORTS section and a different patch. ----- Original Message ----- From: "Luke Dunstan" <cod...@ho...> To: <min...@li...> Sent: Wednesday, 12 March 2003 11:47 Subject: [MinGW-dvlpr] Re: [ mingw-Bugs-698615 ] ld crash with '-shared' > > I agree that this change would remove the need for opt_name, so I think that > the redundant rules should be removed because otherwise the parser becomes > confusing. However, I believe that the patch breaks the handling of the > "IMPORTS" section, but I wasn't even aware of such a section until now so > I'm not sure of its purpose. I also haven't found any useful MSDN > documentation on this section except a little about 16-bit apps. Here are > the rules: > > impline: > ID '=' ID '.' ID '.' ID { def_import ($1, $3, $5, $7, > -1); } > | ID '=' ID '.' ID '.' NUMBER { def_import ($1, $3, $5, 0, > $7); } > | ID '=' ID '.' ID { def_import ($1, $3, 0, $5, > -1); } > | ID '=' ID '.' NUMBER { def_import ($1, $3, 0, 0, > $5); } > | ID '.' ID '.' ID { def_import ( 0, $1, $3, $5, > -1); } > | ID '.' ID { def_import ( 0, $1, 0, $3, > -1); } > ; > > The def_import() function does just concatenate the module name and the > DLL's file extension in the first two cases, but the patch will prevent the > parser from distinguishing the function name (the last ID) from the DLL > name. Some possible solutions (instead of the patch): > > 1. Define a "dotted_name" rule that parses an ID followed by any number of > dots and IDs, then concatenates them. The dotted_name would replace ID in > only "expline" and "opt_equal_name". I'll try this one I think. I tried something similar and it worked but I didn't trust my knowledge of yacc/bison so I submitted the less intrusive patch. === 8< === > If the IMPORTS section doesn't need to be supported in binutils anyway then > that would be easy, but if it does then I guess there should be a test case, > if we can find an example of its use. Other sections like "SECTIONS" are > probably obsolete too. > > BTW, MSVC 6 generates something like this for an unnamed namespace, and > processes it like any other export: > > ?foo@?%C:\devl\test\dlltest\dlltest.cpp42368689@@YAXXZ > > Luke > > > > _________________________________________________________________ > MSN Instant Messenger now available on Australian mobile phones. Go to > http://ninemsn.com.au/mobilecentral/hotmail_messenger.asp > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Danny S. <dan...@cl...> - 2003-03-13 01:09:42
Attachments:
deffilep.diff
|
----- Original Message ----- From: "Luke Dunstan" <cod...@ho...> To: <min...@li...> Sent: Wednesday, 12 March 2003 11:47 Subject: [MinGW-dvlpr] Re: [ mingw-Bugs-698615 ] ld crash with '-shared' > > Danny, > > I was going to reply about your suggested patch but then I decided to let > the binutils mailing list (which I am not subscribed to) deal with it, but > I'm still not sure about it. Luke, this seems to work. I can't find any useful examples of IMPORT, but just to be safe this preserves the former behaviour. Forwarding of exports is supported in dlltool but not by ld --shared. The dot_name usage is involved there as well. eg EXPORTS foo = msvcrt.strlen ;bar = ntdll.dll._alldiv ; I'm not sure if the second usage is correct/documented Do you want to submit this since you caught the bug. If not, could you please review before I make another bison-blunder Danny ChangeLog 2003-03-13 <your_name_here> * deffilep.y (def_lex): Revert 2003-03-12 change. (dot_name): New id type and rule. (expline): Use instead of ID. (opt_equal_name): Likewise. |
From: Danny S. <dan...@cl...> - 2003-03-13 01:56:07
|
> Hey I didn't know you could do this but it works (or used to before yesterdays patch) // lldiv.c extern __stdcall long long _alldiv (long long num, long long denom); long long lldiv(long long a, long long b){ return _alldiv (a,b); // lldiv.def IMPORTS _alldiv@16 = ntdll.dll._alldiv gcc -shared -o lldiv.dll lldiv.def lldiv.c Danny |