Ordering of itab.h and itab.c varies between runs and Python versions… #145
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
… #144 (#144)
scripts/ud_opcode.py: Working on #120, because I hadn't realized that someone had already got properly to the root of it, in #139, I was hampered by the output, specifically itab.h, changing order every time I ran:
UD_OPCODE_DEBUG=1 python3 ../scripts/ud_itab.py ../docs/x86/optable.xml .
... from the libudis86/ directory. The getLabels change here fixes that to be in a defined ordering.
The mergeSSENONE change fixes the ordering differences I see in itab.c between running the above command and similar with python2, by iterating over each table in the same style as used by genOpcodeTable in class UdItabGenerator in scripts/ud_itab.py.