Re: Stdcall support in binutils

[DJ Delorie <dj at delorie dot com>]

> Well, I'm writing programs for Windows almost 10 years and have used
> Borland and MS tools for that. None of them does require to specifically
> add decorations to the exported names neither in the source, nor in the
> def files.

GCC doesn't require decorations in the source either (nobody does),
but you *must* prototype the functions correctly.  Usually the
windows.h header does this for you.  The point I'm trying to make is
that the decorations indicate that GCC must use a different method to
call the function - different opcodes - and if you (the programmer)
find yourself trying to deal with decoration mismatches, to me it
means that your headers aren't right, because if they were you simply
wouldn't be having linker problems.

Yes, it would be good if the linker could make import libraries and
dlls where the export list is missing the decorations but the import
symbols and the functions have them.  Yes, it's a bug if it doesn't do
this right.  But no, that's not a good reason to try to get decoration
mismatches to `work'.  IMHO, you should be decorating your def file
symbols.

> I'm using gcc 2.95.2 under Linux. Just made a quick test: gcc does not
> add *any* decorations to symbols declared as __attribute__((__stdcall__)).

Linux is not Windows.  It's a completely different ABI.  Since Linux
doesn't support stdcall, gcc on linux doesn't honor it.  Comparing
Windows to Linux is as useless as comparing Windows to Solaris or any
other operating system.

> ld and dlltool have completely different .def file parsers.

Yup, out of neccessity.

> IMO dlltool does a much better job;

Yup.  It's much more mature.  However, there are a few things ld can
do that you can't do with dlltool, like linking directly against a DLL
*without* an import library, and building a dll and import library in
one step instead of five.

> giving .def file to ld directly, I managed to get a not loadable
> dll.

That's a bug that needs to be reported and eventually fixed.

> Instead of having and maintaining both of them, ld should make use
> of the common parser code. I'm sorry, I won't do it myself, it's
> just a suggestion to the binutils developers; I'm very busy with my
> current work.

Understood.  Ideally, ld should be enhanced to do everything dlltool
does, and then dlltool can go away.

> > That's a gcc issue (gcc.gnu.org). The answer is yes, but it was told
> > not to.
> 
> But at least under Linux

Linux is not Windows.

> Does GCC under Linux do something special to achieve that?

GCC has a generic option that lets the target layer tell it where to
put read-only data.  Linux says ".rodata".  Windows says ".text".
It's as simple as that.  Since Windows (the operating system) doesn't
understand the concept of "read only data" putting it in the text
section makes the most sense.