bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/351] [PATCH] dlltool doesn't honour aliases in .def files.


From: carlo at alinoe dot com
Subject: [Bug binutils/351] [PATCH] dlltool doesn't honour aliases in .def files.
Date: 7 Sep 2004 12:06:38 -0000

------- Additional Comments From carlo at alinoe dot com  2004-09-07 12:06 
-------
Ack.  Ok reopened again.
After a long long discussion on this topic on the mingw-users
list (which doesn't have a usable archive for long threads,
only single mails) we reached the point that everyone agrees
and understands the subject ;).  Allow me to include my last
post here:

On Tue, Sep 07, 2004 at 03:24:12AM -0500, Aaron W. LaFramboise wrote:
> Due to some recent confusion on this matter, and the general lack of
> clear examples in general, I have created a small example that shows how
> the internalname element is correctly used in a DEF file.

Ok, thanks.  Now I understand the real meaning of 'internal name'.
All the confusion came from the fact that I interpreted
"exported name" as whatever was visible to the application at
linktime: whatever is exported from the .dll.a, and not what is
exported from the .dll.  As a result, I interpreted 'internal name'
as what is exported by the .dll.

In order to get rid of any further confusion, let me summarize
what means what from now:

'internal name' == symbol name in test.o
'exported name' == symbol exported from test.dll
'imported name' == symbol exported from test.lib (and test.dll.a), and imported
by main.o (the final executable).

And a .def file contains the syntax:

exported_name = internal_name

which is only to be used while generating the .dll from its .o.

The problem we have then is that gcc doesn't add an underscore
to imported stdcall names, while dlltool has no other means
then --add-underscore to fix that problem.

This means that

1) The meaning of the symbols in the .def are CHANGED into
   'imported name'
2) There is no way to fix this problem when there are also
   non-stdcalls symbols, without an underscore being exported
   from the .dll.

Let me clarify point (1).

What --add-underscore does is add an underscore to the name found
in the .def file and use the resulting name as exported name.
This means that it treats the names in the .def file as 'imported
names' and not as exported names.  This is probably the main
reason for my mistake when trying to understand what is what.

Although it isn't really necessary to revert the patch in binutils
(because the .def file is "customized" already as it is all the time)
I do agree that it isn't very nice to change the meaning of 'internalname'
in the .def file just like that, for dlltool.

Nevertheless - we need a solution for the missing underscore when
compiling with gcc.

Like Aaron already said (and Wu too), it is probably best to not
break the legacy behaviour we have.  A solution should be one
that only has effect when a new option is being used.

There two possibilities:

1) We add a new option to dlltool that tries to fix the problem
   with heuristics.
2) We add a new option to dlltool that causes it to treat the
   exported names as imported names (still) and additionally
   treat the internal names as exported names, instead of
   ignoring them.  Basically, my patch but with a command line
   option to enable it.
The heuristics could be:

 - A new option that: Disable --kill-at and --add-underscore
   (because both treat the names in the .def as imported names).

 - Ignore the internal names and treat the exported names as
   exactly that (this means that no more filtering of .def
   or output of pexports is needed).

 - Generate imported names by removing leading underscores
   from exported stdcall symbols.

What do you think?




-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://sources.redhat.com/bugzilla/show_bug.cgi?id=351

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]