value passed in write_cb of uc_mmio_map is not a uint64_t, it is really a uint32_t

[tesuji]

The write_cb of uc_mmio_map has definition:

typedef void (*uc_cb_mmio_write_t)(uc_engine *uc, uint64_t offset,
                                   unsigned size, uint64_t value,
                                   void *user_data);

I would expect the value variable has real uint64_t type. But as shown in this diff (with all tests passed),
value (as a u64) is splitted into 2 parts (u32) and passed each with the equivalent offsets.
This is really surprising and I think we should either:

• don't fix it, and document this behavior.
• or fix this.

[wtdcode]

Thanks for your interests. Is your issue resolved already?

[tesuji]

I'm sorry I don't understand your question. Could you clarify it?

(In the top post, I made a typo. I mean "this diff" instead of "this PR")

[wtdcode]

https://github.com/unicorn-engine/unicorn/wiki/FAQ#memory-hooks-get-called-multiple-times-for-a-single-instruction

[wtdcode]

By the way, a workaround is to play with experimental virtual TLB mode.

[tesuji]

Thanks for the pointer. I got the issue now. My main concern is that
for future users, it could be confusing when debugging this issue again.
Perhaps we could document it in uc_mmio_map document and some functions like that.

(Btw, I changed the written address to be 0x10-aligned, but the mem_write hook still called 2 times.
I just relied on the offset for that.)

[wtdcode]

Thanks for the pointer. I got the issue now. My main concern is that for future users, it could be confusing when debugging this issue again. Perhaps we could document it in uc_mmio_map document and some functions like that.

(Btw, I changed the written address to be 0x10-aligned, but the mem_write hook still called 2 times. I just relied on the offset for that.)

Make sense. I will add a few documents to corresponding APIs (or would you like to contribute?).