Extend uc_open() to specify CPU model

[aquynh]

we need to let users to specify CPU model at the time the engine is initialized. this is highlighted with a recent issue #114 (comment)

one way to do this is to extend uc_open() to contain one more param for CPU model. something like:

uc_err uc_open(uc_arch arch, uc_mode mode, uc_cpu model, uc_engine **uc);

any comments?

[cseagle]

I'm not sure I'm a fan of this. How is the CPU type selected now? Is there a generic x86 type for example? ARM type? In what percentage of cases do you expect that users will want to override the default? If this number is small, then forcing them to specify it every time is a bad UI choice, I think I would prefer an additional:
uc_err uc_set_cpu_model(uc_engine *uc, uc_cpu model);
api to support the small number of cases in which this is desired.

[JonathonReinhart]

Another option is adding something like

uc_err uc_open_ex(uc_arch arch, uc_mode mode, uc_cpu model, uc_engine **uc);

So advanced use cases can pass the model, but the original uc_open signature remains unchanged, and becomes just a wrapper that passes a sane default value for model to uc_open_ex.

[lunixbochs]

Is there a good case for changing the emulated cpu model during execution? If so, the only thing that would make sense to me is a separate API call.

[aquynh]

at the moment for X86 i enabled all the options, so we are using the latest X86 model by default.

another approach for the CPU model is having a new API to customize engine at run-time. with this API, CPU model is just one option to customize - so we leave this open for future options.

uc_err uc_option(uc_engine *handle, int option_type, size_t option_value);

then after uc_open(), we can change the CPU model of ARM engine to ArmV7 like this:

uc_option(handle, UC_OPT_CPU_MODEL, UC_ARM_CPU_V7);

[JonathonReinhart]

Personally I dislike multiplexing lots of generic functionality into a single API like uc_option, unless the functionality can be reasonably handled in a consistent way in the back end (i.e. without a giant switch statement).

I much prefer a concise API like uc_set_cpu_model. These aren't Linux system calls, so I see no reason not to make it explicit.

[lunixbochs]

Updating bindings is easier with a generic function.

[Normmatt]

Any news on this? I'd really like to be able to have two arm cpus running at the same type both being different models (ARM946 and ARM1176).

[lunixbochs]

Writing a 3DS emulator? :)

[Normmatt]

maybe...

[aquynh]

we should not allow to change the CPU model after initializing the engine, so the only place to set the model is inside uc_open(). but it is ugly to have uc_open_ex() just for this, so i think we will have to break compatibility by adding one more argument to uc_open(), like below.

uc_err uc_open(uc_arch arch, uc_mode mode, const char *model, uc_engine **uc);

in which if model = NULL, we go for the default model (for ex, with X86 default model is the latest CPU model, or with ARM it is "cortex-a15")

thoughts?

[aquynh]

i created a new branch https://github.com/unicorn-engine/unicorn/tree/cpu_model to implement the idea above: uc_open() now takes one more argument model in https://github.com/unicorn-engine/unicorn/blob/cpu_model/include/unicorn/unicorn.h#L262, so it is possible to specify CPU model at initialization time. pass NULL to this if you want to use the default CPU model (which is latest model for X86, Arm & Arm64 for now)

the Python binding of class Uc was already updated to accept a default model=None so if we ignore this argument, the default CPU model is used: https://github.com/unicorn-engine/unicorn/blob/cpu_model/bindings/python/unicorn/unicorn.py#L154

@Normmatt : can you test this branch to see if it works for you?

thanks.

[aquynh]

@Normmatt, any feedback on the "cpu_model" branch that provides what you requested?

[Normmatt]

I haven't had a chance to setup a development environment to compile this yet. (Windows)

[aquynh]

@Normmatt, have you tried that branch yet, even on Linux/OSX? let us know if you have any issues.

[aquynh]

any objection if i merge the branch "cpu_model" to "master"?

@cseagle, @enkomio: this needs your attentions since this API change on uc_open() will break the Java & .NET bindings. at the moment Python & Go bindings already supported this.

[enkomio]

No objection for merging, from my side I'll update the .NET binding.

[kitlith]

Any news? I'd like to more closely emulate my platform of choice (Raspberry Pi) by selecting the precice model of CPU it has. This isn't too important to my application though, I think.

I see that the cpu_model branch exists, however, it doesn't appear to be merged in, and is way behind master at this point. Is it because you never recieved the okay from some binding maintainers?

[aquynh]

Let me look at that again to see how best to implement this. It is best if we dont break any API.

[EverOddish]

I'm also interested in specifying a specific ARM CPU model. I've hard-coded it in my own build for now.

[aquynh]

which model do you use?

[wtdcode]

Re-open and link to #1449

[wtdcode]

Closed due to uc_ctl added.