Hmm. Could you send me a disassembly of the thunk as it is actually
generated?
Ok, here you are, directly from Wine's debugger :
Wine-dbgbt
bt
Backtrace:
=0 0x4967487e (wine_glGetString) (ebp=4eb610a0)
Wine-dbgdisas 0x4967487e
disas 0x4967487e
0x4967487e (wine_glGetString): movl
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0257 GS:
EIP:496706f8 ESP:49646944 EBP:4eb610a0 EFLAGS:00010297( R-
00 I S -A-P1C)
EAX:0041b6e2 EBX: ECX:49646948 EDX:49646944
ESI:4eb610a0 EDI:
[snip]
Backtrace:
=0 0x496706f8 (_init+0x13d4) (ebp=4eb610a0)
Patrik Stridvall wrote:
Hmm, EBX is 0. That shouldn't happend. This is perhaps
because the GOT must be reloaded in EBX before the call.
Correct. You need to have the GOT in %ebx before calling any
PLT stub ... (Hmpf. I missed that as well :-/)
Perhaps it worked for me by pure luck. A
[snip]
+print '"\tpopl %ecx\n"' . " \\\n";=0A=
+print '"\tsubl $" #argsize ", %esp\n"' . " \\\n";=0A=
+print '"\tjmp *%ecx\n"' . " \\\n";=0A=
This appears to be broken; you need to *add* the argsize instead
of subtracting it, and furthermore the return address lies now
What about this instead of the last three lines:
print "\taddl $" #argsize ", %esp\n";
print "\tret\n";
I did that and it does not solve the problem : it crashes at the same
GL call (glGetString) but this time at address 0x and not
0x1F00 as before.
How can I help
I have made a small hack (attached) that tries to adapt my Solaris C
patch to this problem. I havn't for various reason been able to
test it so it might (read: will) not work, but it is better than
nothing I hope.
OK, some comments on the patch :
1) you seem to have generated your
I have made a small hack (attached) that tries to adapt my Solaris C
patch to this problem. I havn't for various reason been able to
test it so it might (read: will) not work, but it is better than
nothing I hope.
OK, some comments on the patch :
1) you seem to have generated your
Patrik Stridvall wrote:
+print '#stdcall_name ":\n"' . " \\\n";=0A=
+print '"\tmovl (%esp), %eax\n"' . " \\\n";=0A=
+print '"\tleal " #argsize "(%esp), %edx\n"' . " \\\n";=0A=
+print '"." #stdcall_name ":\n"' . " \\\n";=0A=
+print '"\tmovl (%edx), %ecx\n"' . "
Patrik Stridvall wrote:
+print '#stdcall_name ":\n"' . " \\\n";=0A=
+print '"\tmovl (%esp), %eax\n"' . " \\\n";=0A=
+print '"\tleal " #argsize "(%esp), %edx\n"' . " \\\n";=0A=
+print '"." #stdcall_name ":\n"' . " \\\n";=0A=
+print '"\tmovl (%edx), %ecx\n"' . "
1) instead of generating C code for the conversion (as in
opengl_norm.c), generate some ASM in-line to do it as fast as
possible. The problem with this is how to get the
address of the
'destination' function to put in the ASM...
I'm not sure exacly what you mean
On Wed, May 17, 2000 at 10:25:02PM +0200, Lionel Ulmer wrote:
As for thread safety, for most of OpenGL apps that people will use
with Wine (i.e. games :-) ), there should be no need to have it... So
having a non-thread safe but fast solution that could be compiled in
at configure time could
I don't think a comparison with Windows is that technically relevant,
since the graphic cards drivers are completly different.
Well, I am using NVIDIA's OpenGL drivers... And as far as I know, the
codebase is the same for Windows and Linux drivers. So performance
should be comparable betwenn
Hi all,
After doing some benchmarks, I found out that the OpenGL performance
is not too bad compared to Windows : about 25 % slower on the
Tirtanium benchmark when removing the X11 critical section protection,
50 % slower with it.
Now, I think most of the remaining FPS are lost in the CDECL -
13 matches
Mail list logo
