[Bf-committers] OpenMP issues with msvc2013 builds

[Chad Fraleigh]

On Wed, Aug 6, 2014 at 2:44 AM, Sergey Sharybin <sergey.vfx at gmail.com>
wrote:


> On Wed, Aug 6, 2014 at 3:32 PM, Chad Fraleigh <chadf at triularity.org>
> 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