On Wed, Aug 6, 2014 at 2:44 AM, Sergey Sharybin <[email protected]> wrote:
> On Wed, Aug 6, 2014 at 3:32 PM, Chad Fraleigh <[email protected]> > wrote: > > > > - Try to hack into vcomp120.dll, trying to figure out the variable, > > linking > > > to it and modifying if (so called brain surgery from the blender side). > > No > > > idea if it's doable. > > > > > > > Base on a quick look with Olly, where it looks up the OMP_WAIT_POLICY > > variable, it then compares it to "active" and "passive" and sets a memory > > byte to 1 or 0, respectively. Then that byte is checked two other places > > just before some calls to GetTickCount() and SwitchToThread(). So figure > > out a way to reference that location by name, and changing a byte might > be > > all that is needed. Hypothetically at least. > > > > That's kinda hackish and not real sure how to do this. Also not really fan > of investing time in this. Any volunteers to look into? :) > > It's not ideal, and would be coded to each specific vcompXXX.dll (and patched/updated versions). However, assuming the location of that flag is a fixed offset from the dll image, the general idea might be: - Call GetModuleHandle() for each supported target (i.e. vcomp120.dll, vcomp120d.dll), until one is found. - Calculate the address of the flag from the module base. - Calculate the address of the code where it does the OMP_WAIT_POLICY active/passive checks and verify a few of the static opcode bytes (either verbatim, or with a checksum/hash). - Get the address that code references for the flag, and if it matches the earlier calculation, then consider it validated, and change the flag at that address. - If no supported dll's were found, or couldn't be verified, output a warning to stderr about bad performance. > > - Create a small .exe which we put next to blender.exe and will call it > > > blender-launcher.exe or so. This application will modify the > environment > > > variable and start blender.exe. We could also make it called > blender.exe > > > and rename real blender.exe to blender.bin.exe so all the links and so > > > continues to work. Here's a quick code of this application [2], would > > need > > > to create an icon for it and so but that's details. > > > > > > > Or add a check at the very beginning of blender.exe's main() that checks > > for the variable, and if it isn't set yet, set it, and then exec itself. > > Making sure it is well tested to never get caught in infinite loop (which > > really should only happen if the environment change failed to take hold > > some how). > > > > Not really sure it'll work. If you start exe file which is linked against > the DLL, the DLL will be loaded (and hence it'll have a copy of the > environment already) before loader will give it a contorl to your main() > function. You need to modify the enviornment before the dll was loaded. > > Maybe i'm wrong and running self from the main will load omp dll again? > Basically it would the same as having a small wrapper exe (i.e. a completely new process spawned), only without an extra binary. The only down side with a self execute is when debugging, since the child process will be the real thing to debug. Using a small wrapper or self exec has the same issues (just less obvious when self exec'd). As long as the user manually sets OMP_WAIT_POLICY ahead of time, then it would act normal for debugging (so something that would need to be made clear in the documentation). -Chad _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
