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

[carlo at alinoe dot com]

------- Additional Comments From carlo at alinoe dot com  2004-09-30 11:58 
-------
Bah - that paste is totally screwed up for some reason :/
Here is a new attempt - sorry about that:

On Wed, Sep 29, 2004 at 10:07:41PM +0200, Filip Navara wrote:
> I'm working on getting the Wine (www.winehq.com) build tool to generate 
> only one flavor of .def files (sharable between MSVC and MinGW) that are 
> later used while linking DLLs.

Then I'd like to urge you to use the format that MSVC uses.
That means that a __stdcall function either looks like:

address@hidden

or

foo = address@hidden

Note that from both you can deduce that the original
is a __stdcall.  Apparently everything is assumed to
be a __cdecl at all times (isn't it?). I never looked
at __fastcall's.

> [snip]
> >No idea - I am neither the ld nor the dlltool maintainer.
> >But it seems that you are not doing anything that is duplicating
> >what I had in mind.  However, you better know _exactly_ what you
> >are doing... it is confusing enough as it is without patches that
> >do things that are not very well thought over :p
> 
> Basically I want to do this in .def files:
>       EXPORTS
>       address@hidden
> as in MSVC instead of the MinGW way, where I have to do:
>       EXPORTS
>       address@hidden
> (note the missing underscore)

ok, looks the Right Way to go.

But you also should do:

        EXPORTS
        address@hidden
instead of
        EXPORTS
        address@hidden
where appropriate.

> It may seem like a little nuisance that can be dealt with using standard
> tools (like "sed" or extending the Wine build tool), but I thought I'll 
> take a stub at fixing binutils to accept the MSVC-style .def files first 
> before trying to workaround it.

I think it goes a lot deeper (than 'sed').
I don't know which posts of me you already read; but just to be sure
let me repeat a few things.

The correct picture of how things work is this:

Notation: GNU/MSVC

foo.cc/foo.cpp/foo.h    : char __stdcall foobar(int hello);     
        // __stdcall is a macro on GNU that only adds an attribute
        // to the function.

foo.o/foo.obj           : address@hidden/address@hidden
        // Plus an extra underscore that seems to be always there and
        // never shown except in hex dumps.
        // This is the 'internal name'.

foo.def                 : xyz = address@hidden / xyz = address@hidden   
        // Right-hand-side matches internal name.

foo.dll                 : xyz                                   
        // Whatever is on the left-hand-side of the '=' sign in the .def file.
        // This is the 'exported name'.

foo.a.dll/foo.lib       : address@hidden/address@hidden                         
        // This is what is *should* be, but no tool will generate this
        // they see the source file (header declaration) too and there
        // generate: address@hidden/address@hidden  Hence, the 'imported names'
        // also need to be called 'foobar'.

So, lets make the .def file more practical:

foo.def                 : foobar = address@hidden / foobar = address@hidden
        // Right-hand-side matches internal name, left-hand-side
        // matches the 'exported name'.

OR
foo.def                 : address@hidden/address@hidden
        // Matches internal name and exported name.
        // In practise there will be a mismatch if you use a mixture
        // of MSVC and GNU though (ie, using address@hidden on GNU might
        // still mean that the internal name is address@hidden).

foo.dll.a/foo.lib       : address@hidden/address@hidden
        // What I call 'imported name' (although this is what the archive
        // exports). This is the same as the internal name IF BOTH USE THE
        // SAME HEADER FILE (declaration).  But because the .dll might be
        // compiled with another compiler there might be a mismatch of
        // underscore.

So, we assume that the application source also contains
char __stdcall foobar(int hello); and the object files contain:

app.o/app.obj           : address@hidden/address@hidden
        // With a possible underscore mismatch with the internal name.
        // When GNU is used with one and MSVC on the other.  This MUST match
        // the 'imported name' however: .dll.a must contain address@hidden and
        // a .lib will contain address@hidden, as they do (see above).

Now - what were MY posts all about in regard of the above?
That was about generating the foo.dll.a with dlltool from the .def.
Suppose you don't have a foo.dll.a but you DO have a MSVC .def.
Then the .def contains:

foobar = address@hidden (A)
OR
address@hidden          (B)

and you need to generate a foo.dll.a that contains exported name 'foobar' (A)
or 'address@hidden' (B) but imported name 'address@hidden' (see foo.dll.a 
above).

How can the dlltool do this?  The way it works AT THE MOMENT is a broken
concept imho; it works like this:

You have (manually) create a .def file that contains:

address@hidden = whatever
OR just
address@hidden

Note that this .def file has nothing to do with the original .def file.
The left-hand-side is now the 'imported name', horrible.

That you use the commandline option (of dlltool) --add-underscore, and
it will use 'address@hidden' as 'exported name'. Done.  Done? No, not if you
also have functions in that .dll that are not __stdcall's.

My proposal is now to add a new commandline option to dlltool that
will work as follows: 1) You don't have to change the .def anymore.
So we have:

foobar = address@hidden      (A)
OR
address@hidden               (B)

Then dlltool will deduce the 'exported name' by taking the left-hand-side
(foobar in case A and address@hidden in case B) and construct the 'imported 
name'
by *adding* an underscore to __stdcall functions, as well as adding the
@<n> part.  This means, that if we have:

xyz = address@hidden

then it will generate address@hidden as 'imported name'.  And when you have just

xyz

then it will generate 'xyz' as 'imported name'.

[...]
Carlo Wood



-- 


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.