search

diasurgical / devilution-comparer

Small helper tool to aid comparing functions between devilution and the original binary
The Unlicense
21 stars 9 forks source link

A diff for a specific function #18

Open sskras opened 5 years ago

sskras commented 5 years ago

In devilution's #1122 @AJenbo responded about checking bin-exactness of a function in CI:

@sskras https://travis-ci.org/diasurgical/devilution/jobs/528380611 line 595 it's hard to have it any more automatic than that. It has been used to detect issues previously but for something like this, it's not of much help, though it does confirm the fix.

Thanks. The output looks still a little bit too scarse to be sure. I think it can be advanced. Will post details below. Please point me if I am missing something.

sskras commented 5 years ago

it's hard to have it any more automatic than that.

I thought that two listings (orig.asm and compare.asm) that this command line generates..:

devilution-comparer ...\Diablo_orig.exe devilution\bld\WinRel\Diablo.exe 0x303EF InitMonsterTRN

... can be easily used to produce a more verbose output for a given function. My biggest concerns here would be:

(1) identifying the names of the functions changed by a patch; (2) finding out the original offsets for them.

How do folks think, is there anything non-doable?

AJenbo commented 5 years ago

This is already a feature in devilution-comparer, and is how the tool is being used locally. All function offsets are known via https://github.com/diasurgical/devilution-comparer/blob/master/comparer-config.toml and the generated PDB.

The problem is that https://github.com/diasurgical/riivaaja has no way of knowing what function was cleaned up by a given PR or what it was like previously. The first could be solved by having riivaaja compare every function individually. But to avoid having it show a list of 2k functions we need a way for it to know the state of the previous commit so that it can filter it down to only show what has changed.

Code quality tools like Jenkins, Codacy and Code Climate solves this by having a service where it stores the previous results and then compares with that for any new PRs, but that requires setting up an infrastructure (could be as simple as a key value commit-hash => 2k line text file) that riivaaja can then read and write from. The big problem here is security, reliability and cost.