Base of immediate changes when sym_resolver is defined

[ImpossibleOctopus]

I've observed this in the Python version. If a sym_resolver is defined, all immediates will be interpreted as hex values.

# normal behavior
ks = Ks(KS_ARCH_X86,KS_MODE_64)
encoding, count = ks.asm('mov rax, 80',as_bytes=True)
md = Cs(CS_ARCH_X86,CS_MODE_64)
for ins in md.disasm(encoding,0):
    print(f'{ins.mnemonic} {ins.op_str}')

The above code will print mov rax, 0x50, with keystone correctly interpreting the immediate as a decimal.

# abnormal behavior
ks = Ks(KS_ARCH_X86,KS_MODE_64)
def sym_resolver(sym,val):
    return False
ks.sym_resolver = sym_resolver
encoding, count = ks.asm('mov rax, 80',as_bytes=True)
md = Cs(CS_ARCH_X86,CS_MODE_64)
for ins in md.disasm(encoding,0):
    print(f'{ins.mnemonic} {ins.op_str}')

The above code will print mov rax, 0x80, with keystone incorrectly interpreting the immediate as a hexadecimal.

I've also noticed other inconsistencies occur when the sym_resolver is defined, but I haven't been able to isolate any others yet like I have here. This issue might be related to issue #351

[SamuelAl]

I have noticed this error when compiling for ARM. Any solution for this?

[Negative-3U]

I have noticed a similar issue when I tried to compile some ARM64 code including floating-point immediates:

import keystone
ks = keystone.Ks(keystone.KS_ARCH_ARM64, keystone.KS_MODE_LITTLE_ENDIAN)
print(ks.asm("fmov s0, #0.0"))

This will work correctly and print ([224, 3, 39, 30], 1) as the result. But after I defined a sym_resolver:

import keystone
ks = keystone.Ks(keystone.KS_ARCH_ARM64, keystone.KS_MODE_LITTLE_ENDIAN)
ks.sym_resolver = lambda s, v: False
print(ks.asm("fmov s0, #0.0"))

This time it will print (None, 0), just the same result with print(ks.asm("")).

[bbqz007]

the problem focus on ks_option.

there is hard coding to force radix to 16 when calling ks_option.

change assembly style or sym_resolver would call ks_option either.

i have issued it on #571