[RFC] refactor: make hook callbacks sound

[Jvlegod]

Ref #14

• Introduce HookContext as the callback API.
  • We need to perform CPU operations within the callback.
  • We cannot create a second unicorn owner within the callback.
• use Box replace Rc the emulator.

what's more: Perhaps we should rename new_with_data to new and make it take only arch and mode.

[Jvlegod]

How about this refactor? :>
I would like to hear your suggestions.

[PhilippTakacs]

I just had a quick look. I'm not quite sure what exactly you want to make more sound. Can you explain a bit more what is the problem you want to solve.

Also with this patch the user_data is practical disabled. For small examples it is not that bad to replace the user_data with closure, but for bigger code it quickly gets ugly.

[PhilippTakacs]

Another problem is that you need now to implement every api twiche (one time for the Unicorn struct and one time for the HookContext).

[Jvlegod]

I'm not quite sure what exactly you want to make more sound.

To be honest, the goal of this patch is to fix an aliasing problem in the old callback.

HookContext is intended to give callbacks access to the current engine handle without creating another Unicorn owner. Box provides unique ownership of UnicornInner.

We can see the an example:

In the old imp.

The callback could modify the same internal state through a second Unicorn while the original Unicorn was still in use by emu_start.

• uc -> Rc<UnsafeCell>
• also, callback_uc -> the same Rc<UnsafeCell>

let mut uc = Unicorn::new(Arch::X86, Mode::MODE_64).unwrap();

uc.add_code_hook(0x1000, 0x2000, |callback_uc, _, _| {
    callback_uc
        .reg_write(RegisterX86::RAX, 1)
        .unwrap();
})
.unwrap();

uc.emu_start(0x1000, 0x2000, 0, 0).unwrap();

I wonder if there have a better way?

Another problem is that you need now to implement every api twiche

Yes, I have also thought about this question. I think this PR just a draft.

[PhilippTakacs]

It might work using uc_emu_start() as a freestanding function taking ownership over the unicorn struct and giving it back on return.

[Jvlegod]

It might work using uc_emu_start() as a freestanding function taking ownership over the unicorn struct and giving it back on return.

Yes, it's a good idea.

But from a user experience perspective, these approaches would seem very strange.

Maybe you mean:

let mut uc = Unicorn::new_with_data(Arch::X86, Mode::MODE_32, 0u64).unwrap();

// it's strange 
uc = uc_emu_start(uc, CODE_START, CODE_START + code.len() as u64, 0, 0);

// or like
uc = uc.emu_start(CODE_START, CODE_START + code.len() as u64, 0, 0);