Add MSVC implementations for ULong__maxIndex and ULong__minIndex

[0xbc]

Builds are currently broken for pyvex on MSVC due to a couple of issues. One is here in the vex project (which I'll describe below) and one is in the pyvex project, which I've submitted another PR for (see angr/pyvex#70).

Currently, vex is using a couple of gcc builtin functions which, unsurprisngly, aren't present in the MSVC ecosystem. There are some very similar builtins in MSVC (_BitScanForward64, _BitScanReverse64) which would have done the job with some minor tweaks. However, those builtins are only present in the 64-bit compiler, which is problematic given that the default VS2015 developer prompt has the 32-bit version of cl.exe on its path.

As such, I've come up with a 32-bit friendly solution by adding some implementations of the relevant algorithms from https://chessprogramming.wikispaces.com/BitScan. I haven't formally verified my implementation (and I lack the wizardry to fully understand the implementations I'm using), but from the limitied testing I've done, the results they're producing look sane (and identical to the output from the gcc functions).

If you'd prefer an alternate strategy for resolving this though, let me know and I'll go back to the drawing board.

[rhelmot]

god dammit! I thought I fixed the MSVC build last month!

this is a little complicated because we're in the process of trying to upstream our patches to valgrind. I'll merge this, but do note that you're submitting a pull request to a GPL project, this patch is licensed under the terms of the license at the top of each file, etc etc, and I may change it according to whatever the valigrind maintainers want.

Does this fix (along with the pyvex one) fix the MSVC build entirely, or is there still work to do?

[0xbc]

After I submitted the PR I noticed simuvex was broken as well - I think it was due to a missing pyvex export but I didn't get time to resolve it yesterday. Maybe hold off on the merge until I can confirm everything's building again. Msvc build was definitely working a couple of months back - I hadn't been rebuilding the native bits in the interim so not sure when it broke exactly. On Apr 11, 2017 04:29, "Andrew Dutcher" <notifications@github.com> wrote: god dammit! I thought I fixed the MSVC build last month! this is a little complicated because we're in the process of trying to upstream our patches to valgrind. I'll merge this, but do note that you're submitting a pull request to a GPL project, this patch is licensed under the terms of the license at the top of each file, etc etc, and I may change it according to whatever the valigrind maintainers want. Does this fix (along with the pyvex one) fix the MSVC build entirely, or is there still work to do? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#8 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHMJ-omUegc8EXcilHLJbckCIndHc3Ysks5runwFgaJpZM4M4Ymc> .

[0xbc]

OK, MSVC build seems to be working and running after adding some extra exports to pyvex.def in the other PR (and a bunch of example scripts from angr-doc run fine). (Note that I used the setup.bat from angr/angr-dev#16 to build it.)

The code from the website I used to implement bit-scanning seems to be licensed as CC BY-SA 3.0. Is that going to be a problem? Apart from that, no licensing concerns from me.

[rhelmot]

If there are problems, I'm sure we'll find out about them :)