Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with ud_opcode.py and Python 3.5 #120

Open
Rudedog9d opened this issue Jan 17, 2017 · 2 comments
Open

Compatibility with ud_opcode.py and Python 3.5 #120

Rudedog9d opened this issue Jan 17, 2017 · 2 comments

Comments

@Rudedog9d
Copy link

There is a TypeError Raised by the following code in ud_opcode.py when run in Python 3.5:
TypeError: %x format: an integer is required, not float

    for k, e in entries:
        if isinstance(e, UdOpcodeTable):
            self.log("%s    |-<%02x> %s" % (indent, k, e))
            printWalk(e, indent + "    |")
        elif isinstance(e, UdInsnDef):
            self.log("%s    |-<%02x> %s" % (indent, k, e))

Purposed fix: Typecast the float k to an integer. (self.log("%s |-<%02x> %s" % (indent, int(k), e)))

Would this cause problems? The built in function k.hex() could be used but this produces a string, which would then not be format-able.

@woodruffw
Copy link

This is also preventing mishegos, which fuzzes this project, from upgrading its environment: trailofbits/mishegos#1606 (comment)

@martindorey
Copy link

A second pull request that fixes this, in what's imo a less elegant way, is at 9c11d83. A third pull request that fixes this is in #139. That, imo, is the most elegant of the three, getting rid of the unnecessarily floating point numbers at the root of the issue. I confirm it's correct and complete.

martindorey added a commit to martindorey/udis86 that referenced this issue May 10, 2023
…mt#144 (vmt#144)

scripts/ud_opcode.py: Working on vmt#120, because I hadn't realized that someone had already got properly to the root of it, in vmt#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants