Update to VS2015, Begin Offset API integration

[stevemk14ebr]

No description provided.

[aquynh]

i am still not convinced about having these info in the instruction structure, given that it is more towards encoding than decoding. let me think more about this PR.

btw, this should go to the "next" branch if it is merged, rather than the "master" branch.

thanks.

[stevemk14ebr]

I understand your hesitation but as a library that prides itself as having detailed instruction information i think it is important to include information such as this. Without such it's impossible to do some specific tasks, which would require switching to a different disassembly library, something i find very undesirable.

[aquynh]

i am still considering everything. meanwhile, you can always maintain the fork yourself, which is not expensive as this X86 code is quite stable - like what the author of #331 is doing.

thanks.

[ionescu007]

It looks like this information would be useful if someone wanted the
ability to re-write certain instructions easily, such as in an emulator
analyzing and patching the byte stream.

Best regards,
Alex Ionescu

On Sat, Aug 8, 2015 at 7:37 AM, Nguyen Anh Quynh notifications@github.com
wrote:

i am still considering everything. meanwhile, you can always maintain the
fork yourself, which is not expensive as this X86 code is quite stable -
like the author of #331 #331 is
doing.

thanks.

—
Reply to this email directly or view it on GitHub
#444 (comment).

[aquynh]

On Sat, Aug 8, 2015 at 8:06 AM, ionescu007 notifications@github.com wrote:

It looks like this information would be useful if someone wanted the
ability to re-write certain instructions easily, such as in an emulator
analyzing and patching the byte stream.

yes that is the main reason why this is needed.

thanks,
Q

[stevemk14ebr]

I will be maintaining my fork as you suggested and will attempt to expose the suggested relative api in the cleanest manner i can. Thanks for putting Polyhook in the showcase btw!

[obs1dium]

I'd be very interested in having this as well, since I need to reliably determine the position of the ModR/M byte. udis86 for example provides the very handy modrm_offset.

[stevemk14ebr]

Check my branch i believe i implemented that
On Aug 26, 2015 9:53 AM, "obs1dium" notifications@github.com wrote:

I'd be very interested in having this as well, since I need to reliably
determine the position of the ModR/M byte. udis86 for example provides the
very handy modrm_offset.

—
Reply to this email directly or view it on GitHub
#444 (comment).

[obs1dium]

Yes, I was going to quickly implement it myself but then found this PR. Hopefully it'll get merged into the next branch.

[kokole]

I'm also looking forward to this, would be a great addition. By the way, it would be much better if there was a flag or a bool somewhere to check if certian fields of the structs are actually valid. For example, in cs_x86::disp the value could be 0, but it also means that it's irrelevant, which makes no sense.

[aquynh]

this is already handled in https://github.com/aquynh/capstone/tree/encoding. will review to merge this branch into "next" soon, thanks.