http://bugs.winehq.org/show_bug.cgi?id=10273
--- Comment #9 from Anastasius Focht focht@gmx.net 2007-11-04 11:29:50 --- Hello,
@Peter Beutner: good point with
-- quote -- __i686.get_pc_thunk.bx call it dislikes because it determines that it goes outside of the dll image. -- quote --
I wrote earlier "... the call should still considered harmless seen from tracer perspective, because it remains in code section .." and missed the fact that this little code snippet is indeed *outside* of PE dll section boundary (but within same ELF .text section) .. *bangs his head*. Thanks for the hint ;-)
Additionally I ran some debugging series, gathering some statistics. I hope bugzilla doesn't mess all the tables up...
used: wine-0.9.48-196-gbeab2c1
How to read the data:
c1,c2,c3 are statistical values, calculated from all entry point code (all named exports) of each library (tracer). They are required to be below given threshold "condition". The conditions are hard coded and the same for all system libraries.
Hex values are percent (0x64 = 100%, 0x32 = 50% ...) "*" means condition not satisfied
standard:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x59 0x53 0x5D 0x5F c2: 0x46* 0x47* 0x50* 0x3C c3: 0x43 0x4B 0x4B 0x5A
(c2 is not met for kernel32, user32, gdi32)
with relay:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x61* 0x63* 0x63* 0x5F c2: 0x59* 0x64* 0x64* 0x3C c3: 0x00 0x00 0x00 0x5A
(c1 and c2 are not met for kernel32, user32, gdi32)
with WINE_NO_TRACE_MSGS and WINE_NO_DEBUG_MSGS (tracing code compiled out):
kernel32 user32 gdi32 condition (cx < threshold) ------------------------------------------------------------------- c1: 0x51 0x4B 0x57 0x5F c2: 0x38 0x28 0x44* 0x3C c3: 0x39 0x3E 0x43 0x5A
(c2 is not met by gdi32)
*** Now the interesting ones ***
kernel32, user32, gdi32 compiled without -fPIC:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x20 0x10 0x19 0x5F c2: 0x07 0x01 0x05 0x3C c3: 0x00 0x00 0x00 0x5A
(significantly dropped, all conditions are met)
200 fake data exports (aliased to 0 DWORD value):
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x4A 0x41 0x3F 0x5F c2: 0x37 0x2A 0x26 0x3C c3: 0x38 0x3B 0x33 0x5A
(all conditions are met)
200 fake data exports (aliased to 0 DWORD value) + relay:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x51 0x4D 0x44 0x5F c2: 0x40* 0x3B 0x2E 0x3C c3: 0x00 0x00 0x00 0x5A
(c2 is not met for kernel32, so "relay" feature is not "safe" to use)
400 fake data exports (aliased to 0 DWORD value):
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x40 0x25 0x30 0x5F c2: 0x25 0x20 0x18 0x3C c3: 0x30 0x30 0x27 0x5A
(all conditions are met)
400 fake data exports (aliased to 0 DWORD value) + relay:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x46 0x3F 0x34 0x5F c2: 0x2E 0x29 0x1B 0x3C c3: 0x00 0x00 0x00 0x5A
(all conditions are met)
===================================
The reason why +relay shifts statistics to the worse is because relay stubs have get_pc_thunk.bx in entry code.
Now the question remains whether to drop -fPIC for these libraries or finding a way to relocate the "get_pc_thunk.bx" code snippet into PE section boundaries. There is one interesting thing I found while dumping kernel32 ELF sections:
7b8303fc l F .text 00000000 .hidden __i686.get_pc_thunk.cx 7b8140e7 l F .text 00000000 .hidden __i686.get_pc_thunk.bx
The address of "__i686.get_pc_thunk.cx" is within "visible" PE section space (starts at 7b820000) whereas "__i686.get_pc_thunk.bx" is not. Both calculate global offset table addresses (choice is probably made by compiler what register does not need to be saved in that code context). If the code location could be fixed to "visible" PE section space like for the get_pc_thunk.cx we might fix this problem while keeping -fPIC.
--- snip --- Any greater version of safedisc2(>= 2.6x?) seems to have additional checks and it fails again with the usual "ExitProcess( 0xfeedface)". --- snip ---
Could you elaborate which games? I have successfully tested the Battlefield game series which have SafeDisc 2.5 and 2.8 (either with dummy exports or by dropping -fPIC). I've also tested one SafeDisc 3.x (doom3) and one 4.x game (BF2). Maybe we're seeing different issues.
Regards