CPU state API about unicorn

[aquynh]

there are a lot of internal data in CPU state that is not nice to leak out to external app.

so i think it is better to have a new API to retrieve all the CPU registers in one run. this simply requires a new structure like your uc_x86_state for every architectures. implementation is trivial.

[JonathonReinhart]

For x86 where there are aliased / overlapping registers, we could probably handle this consistently and efficiently with a carefully-crafted set of anonymous unions, e.g.:

struct uc_x86_state {
    union __packed {
        uint64_t rax;
        uint32_t eax;
        uint16_t ax
        struct __packed {
            uint8_t al;
            uint8_t ah;
        };
    };

    // ...
};

Although this may make writing bindings more.... interesting.

[aquynh]

yes this looks good.

so we will need 2 new APIs like uc_reg_read_all() & uc_reg_write_all() - or perhaps somebody come up with better names. please go ahead implementing these APIs.

[JonathonReinhart]

I partially implemented the above structures as above for x86, if anyone is interested:

https://gist.github.com/JonathonReinhart/bb0897216ac0688c3d2f

[lunixbochs]

Can't speak for anyone else but I don't really care about the API exposing overlapping registers. It's arch-specific anyway so I'm just as happy masking myself in that case. I'd rather have a simpler API (a list of uint64_t) than a ton of arch-specific structs.

[lunixbochs]

What about this API?

uc_get_regs(handle, uint32_t *names, uint64_t *values_out, uint32_t length);
uc_set_regs(handle, uint32_t *names, uint64_t *values_in, uint32_t length);

uint32_t names[] = {RDI, RSI, RDX, RCX, R8, R9};
uint64_t values[6];
uc_get_regs(handle, names, values, 6);
values[0] = 1;
uc_set_regs(handle, names, values, 6);

It's not the safest API (potential for off-by-one errors) but I'm mostly aiming for fast. It'd be even better if this only called a minimum number of functions internally (that is, inline the loop over switch if possible. maybe can make the compiler do that for you, or redeclare it as inline and make two wrappers).

Once you start piling on abstractions, 15+ reg_read() for every instruction executed can't be fast :)

The alternative in my mind is:

uint64_t regs[UC_X86_REG_COUNT];
uc_get_all_regs(handle, regs);
regs[UC_X86_REG_RDI] = 1;
uc_set_all_regs(handle, regs);

where the main downside here is that some architectures have a LOT of regs, which is why I'd prefer the former.

[aquynh]

to keep it simple, i think it would be better if the new APIs get all the registers at once, not only those selected one.

about API names, to be consistent, uc_reg_read_all() & uc_reg_write_all() sound OK to me. any other ideas?

[lunixbochs]

I don't think we should include vector registers (32 512-bit AVX registers is 16KB), and it should be either a uint64_t array indexed by the register's enum, or a flat union-free struct (though a struct is much harder to integrate with bindings).

[lunixbochs]

I'm satisfied by the performance and ability of #506 to handle weird register types, so I'm closing this in favor of the speed concern in #318