This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Relato do progresso na resolução do bug do stdcall
- To: <egcs at cygnus dot com>
- Subject: Relato do progresso na resolução do bug do stdcall
- From: "Antonio M. O. Neto" <anmendes at cruzeironet dot com dot br>
- Date: Thu, 11 Jun 1998 20:44:26 -0300
Hello,
I am writing to tell my progresses in the resolution of the " bug " that
impedes the use of __stdcall inside in classes of Windows 95 (I am compiling
for i386-pc-mingw32). As it was identified by several people, the compiler
simply ignores (the stdcall) when this is placed inside of a class. This
problem I got to solve, the compiler is now generating the correct code for
the stdcall in classes.
That amazes!!!
Nor so much.
When you use the virtual " definition ", the compiler it creates the
structure exemplified below (I used the file " ddraw.h " (Directx5) as
example:
__vt$11IDirectDraw:
.word 0
.word 0
.long ___tf11IDirectDraw
.word 0
.word 0
.long _QueryInterface__11IDirectDrawPvPPv
.word 0
.word 0
.long _AddRef__11IDirectDraw
.word 0
.word 0
.long _Release__11IDirectDraw
------------------------------------------------
Repair that for each method declared as virtual, the compiler generates two
" word ", and later it defines the pointer for the method as being " long ".
This example everybody is already tired of knowing that doesn't work. Making
the necessary alterations, which everybody already knows that it works, the
generated code is another:
.file " teste1.c "
gcc2_compiled.:
___gnu_compiled_c:
.text
.align 4
.globl _main
_main:
pushl %ebp
movl %esp,%ebp
pushl %ebx
call ___main
pushl $0
movl _ID+8,%ebx;----------------------> Function " Release " call here
call * %ebx
L1:
movl -4(%ebp),%ebx
leave
ret
.comm _ID,92
Repair that this case, that is what it works, only that it doesn't use
methods and classes, the pointer for the function " Release " is placed
starting from the eighth byte of the structure and in the previous case
(with classes), the pointer (virtual method) it is placed in the byte of
position 48 (that is another completely different method.
In spite my success in the recognition of the stdcall, this won't advance of
anything if this other problem be not solved. At least now all we already
have notion from where to begin.
At once I thank the attention and I accept suggestions of as to solve the
problem. I will continue trying to solve this problem inside of my readiness
of free time.
Antonio Mendes of Oliveira Neto-Brazil: anmendes@cruzeironet.com.br
Ps.: To remove the message of " stdcall directive ignored ", go until the
file
/egcs-19980531/gcc/config/i386/i386.c
and change in
if (TREE_CODE (type) != FUNCTION_TYPE
&& TREE_CODE (type) != FIELD_DECL
&& TREE_CODE (type) != TYPE_DECL)
return 0;
increasing
&& TREE_CODE (type) != METHOD_TYPE
Ready, the message will be removed the stdcall it will become interpreted
correctly by the compiler.