This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Attribute questions
Mumit Khan wrote:
> > Q1: Why does egcs complain about __attribute__((stdcall)) when it is
> > used in class member functions?
[snip example]
> It doesn't. Please switch to egcs-1.1.1; egcs-1.0.3 is *very* old by now,
> and lots win32 fixes weren't in it. I believe this particulare oversight
> was fixed on July 28 by Antonio Neto.
> > 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).
>
> Reported by whom? I don't see a bug report.
It wasn't a a bugreport to egcs development, but a message on our
wine-devel list from
Gavriel State <gavriels@corel.com> that some MSVC construct did not work
(and they mentioned using 1.1.1). I have been using 1.0.3 to look at a
couple of other things. If this has been fixed, then I appologize for
the noise, but I was merely looking further into the problem based on
the reports on our lists. I could not do a thorough investigation
because the egcs list is not searchable :-(
Also a message from Douglas Ridgeway <ridgway@winehq.com> stated
(wine-devel list):
! Mumit Khan has looked at this. At one point he had patches
! which fixed some of the problems, but which weren't acceptable
! for integration for reasons I didn't understand.
So I was in the understanding that the problem was'nt yet solved.
Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> Please note that Bertho is probably talking about egcs under
> Linux/ix86, with Linux/ix86 as target, interfacing to Win32
> code, for the Wine (Wine Is Not an Emulator :-) Win16/Win32
> environment on Linux.
Indeed, I forgot to mention this because I thought that it was known
that wine runs on linux... There are some very peculiar things in
windows that you encounter when you try to emulate it under linux.
> > 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).
>
> What problem are you referring to? In its current form, The dllimport
> and dllexport attributes work quite well; most of the remaining problems
> are in the C++ front-end, and mostly to do with the fact that we don't
> really know what heuristics MSVC uses to generate the vtables, rtti
> info etc and may get too many or too few copies. There are a few other
> well-known generic bugs as well, but I just haven't had the time to
> actually fix these (I do know workarounds, so it's not a big issue
> right now).
To parse dll{im|ex}port in the Linux version of egcs (no crosscompiler).
That is the point. This question was also raised by the Corel guys (***
see address of list below). The __declspec is used in windows in a very
special way and that can never work under linux, but it can be a help to
circumvent code-changes.
The problem is basically that winelib (the win32 API) is supposed to
become compile compatible with windows. This means that we want to
compile win32 sources without changing one single line of code (except
for a couple of defines on the commandline). This can nearly be done
except for a couple of incompatibilities as the '\' in pathnames in
#includes. Winelib works with the same library seperation as real
windows has dll. We intend to have dlls encapsulated in elf libraries
(I'm working on this) and produce a compatible import/export table for
run-time linkage (no, it can't be done with elf-dynamic-linkage).
If we do not have any __declspec, then we need to extract the exports
manually or write them manually in a file. This works fine for normal C
(we do this right now), but C++ has the name-mangling which is quite
hard to do by hand. I already suggested that we could write a utility
that extracts the declspec from a preprocessed file, but this means that
we have to parse C/C++ which is a hell of a job. It would be wishfull
(for the large C++ projects as Corel has) to be able to use the
information at hand. If the symbols that have a dll{im|ex}port could be
dumped, then I can use this info without too much trouble to generate
the proper tables. Again, it is not a must have, just easy for large C++
projects.
Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> BTW, I don't think egcs on Linux should be able by default to
> generate braindamaged Win calling conventions. A workaround
> (via asm() perhaps?) might be OK.
This doesn't work. We do not want to change the source. This is a major
issue. I can already generate all the interface that I need, but it is a
hell of a lot of work for C++.
> I'm not sure why Wine needs to implement the dllimport/export stuff.
> These are there only to compensate for the bizarre DLL design, and
> if you're building Wine on non-native platforms that support real
> shared libraries, this shouldn't be an issue, right?
Yes, it is an issue, because real elf-libraries link in a completely
different way. This I have examined closely, and is not solvable without
hacking the runtime dynamic linker. This is not an option as far as I'm
concerned. Thats why I embed a dll in an elf-library.
I am not suggesting that you should generate *any* code at all that
resembles windows. I don't like it myself, but it is really annoying
while trying to implement the win32 api on linux (and other unixes).
For example, it would be a real help to have two extra sections in the
object file. Let me call them ".import" and ".export". These sections
will never get linked into the final executable because the linkerscript
does not contain them or can be discarded at the executable creation
stage. These sections would contain the functions and variables that
have the declspec attribute attached. I will then extract the data from
these section to create the real import/export tables for the dll
embedding.
Greetings Bertho
***
The wine-devel list is archived at:
http://www.integrita.com/cgi-local/lwgate.pl/WINE-DEVEL
The message refered to has the subject "Proposed list of egcs
extensions..." which has been under 'hot' debate.