http://bugs.winehq.org/show_bug.cgi?id=10273
--- Comment #15 from Anastasius Focht focht@gmx.net 2007-11-05 12:31:16 --- Hello,
unfortunately the PE header patch works only for one of the 3 conditions mentioned earlier...
Comparison with previous data (from comment #9):
standard:
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x59 0x53 0x5D 0x5F c2: 0x46* 0x47* 0x50* 0x3C c3: 0x43 0x4B 0x4B 0x5A
with PE header .init section patch (moves PE header before pc thunk code):
kernel32 user32 gdi32 condition (cx < threshold) -------------------------------------------------------------------- c1: 0x59 0x53 0x5C 0x5F c2: 0x46* 0x43* 0x53* 0x3C c3: 0x00 0x00 0x00 0x5A
At least condition c3 is completely satisfied. By doing some dirty stuff *g*, I forced the analyzer to load my own, custom made dll at the point where it checks the system libraries. I ran some series to find more about the meaning of calculated stats values.
--------
The custom dll exports a specific number of functions (10 for percentage values) with pure asm code to control generation of opcodes.
I made some test cases with different nesting levels and calling destinations.
"t_x" = testcase x "n_x" = nesting level x (e.g. func0() { func1(); } func1() { ...} ) "i_fn" = internal function "exp" = exports
t_1: 10 data exp, init with 0 t_2: 10 exp, call to i_fn, n_1, simple register calculation t_3: 10 exp, call to i_fn, n_1, emulates get_pc_thunk.bx() t_4: 10 exp, call to i_fn, n_1, { mov eax, <outside_of_pe_dest> ; jmp eax } t_5: 10 data exp, init with 0xE8 (call xxx opcode) to check if the analyzer makes difference of section (.data vs .text) t_6: 10 exp, call to i_fn, n_1, calls GetModuleHandleA("kernel32.dll") t_7: 10 exp, call to i_fn, n_10, at n_10 call GetModuleHandleA("kernel32.dll") - nesting level test t_8: 10 exp, call to GetModuleHandleA("kernel32.dll") t_9: 5 exp, call GetModuleHandleA("kernel32.dll") and 5 exp, call to i_fn, n_1, calls GetModuleHandleA("kernel32.dll")
t1 t2 t3 t4 t5 t6 t8 t9 condition (cx < th) -------------------------------------------------------------------- c1: 0x00 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x5F c2: 0x00 0x64 0x64 0x64 0x64 0x64 0x64 0x32 0x3C c3: 0x00 0x00 0x00 0x64 0x50 0x00 0x64 0x32 0x5A
Well ... determining the meaning of conditions seem to be pretty hard because several information is taken into account and I only varied call destination and nesting level. I dropped the idea of testing various other opcode sequences/entry signatures (length of sequences, stack parameters, ..) due to time constraints ...
c3 seems to be directly related to the destination of first call/jump encountered at nesting level 0. So the get_pc_thunk.bx() location problem was only one reason.
That makes two options left: drop -fPIC or go with fake data exports. Though dropping -fPIC for the libraries in question seems to be more natural solution ;-)
Regards