This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Attribute questions
- To: egcs at egcs dot cygnus dot com
- Subject: Attribute questions
- From: Bertho Stultiens <eklfbs at aau dot dk>
- Date: Fri, 15 Jan 1999 18:02:22 +0100
Hi,
Firstly, let me introduce myself. I am working on Wine (windows
emulator) to support shared libraries (dll encapsulation in elf). Wine
is heavily using the __attribute__ construct in a couple of areas.
We are having a discussion on the Wine-development list about features
that would be wishfull/helpfull for wine-development and I was
wondering about a couple of things concerning attributes, especially in
c++ compilation mode.
Q1: Why does egcs complain about __attribute__((stdcall)) when it is
used in class member functions?
class myclass {
public:
myclass() {}
~myclass() {}
int __attribute__((stdcall)) memberfunc(int);
};
This example issues a warning that the stdcall attribute is ignored
(egcs 1.0.3; it has been reported to fail in egcs 1.1.1). I can only
see a reason to ignore this attribute for con- and destructors because
their calls are implicitly hidden and a mix causes problems. But all
other memberfunction, beit virtual or not, can only be called if the
compiler compiled the class definition/prototype (indirect calls are
also prototyped in some way). So the calling convention should never
interfere with the code-generation because it is known how the call
should be generated at all times.
This construct is required for c++ programs to compile for wine because
many dlls have member functions in the exporttable and these are
typically declared stdcall. Is there a possibility to see this
functionality coming in a next release?
Q2: I also encountered the VCish construct __declspec(dll{im|ex}port)
while browsing the archives (converted to
__attribute__((dll{im|ex}port))). I made up out of that post that it
was targeting the win32 version of egcs, but we are debating thus
construct for wine as well.
I very well realize the extend of the declspec problem/impact and was
wondering whether anyone had been looking into this construct closer
since the mailing list post (egcs mailing list May 1998).
TIA.
Note: Please add my e-mail address in your CC if you reply because I am
not registered on this list (too much load for my inbox).
Greetings Bertho