Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Possible to bind uc_mem_map_ptr? #27

Closed
petmac opened this issue Feb 7, 2018 · 6 comments
Closed

Possible to bind uc_mem_map_ptr? #27

petmac opened this issue Feb 7, 2018 · 6 comments

Comments

@petmac
Copy link

petmac commented Feb 7, 2018

Is it possible to bind uc_mem_map_ptr, thereby allowing the user to provide their own memory? Maybe this isn't reasonably to do with Rust, I don't know it well enough.

@ekse
Copy link
Collaborator

ekse commented Feb 7, 2018

I think it should be possible. Do you have an idea what kind of memory buffer you would like to use? I want to be sure the implementation I come up with is working in your use-case.

@petmac
Copy link
Author

petmac commented Feb 7, 2018

It's for a multithreaded emulator, I was debating whether a rewrite in Rust is feasible.

Currently a 4GB address space is reserved using mmap on macOS and VirtualAlloc on Windows and pages get committed as required.

That address space pointer is passed to multiple Unicorn instances using uc_mem_map_ptr.

@ekse
Copy link
Collaborator

ekse commented Feb 8, 2018

That's a pretty cool project! I pushed a branch with mem_map_ptr support added (see #28). ptr is passed as a pointer to the buffer, the type is generic (*mut T) so I think it should be useable with pretty much any type of memory. I added a test that shows how to use use an array or a Vec as examples.

I think that should work for your use case?

@petmac
Copy link
Author

petmac commented Feb 8, 2018

Thank you. I'm new to Rust so I can't say for sure, but I imagine as long as I can get that pointer from mmap and ownership isn't taken away from the caller, it should be good.

Thank you for looking into this!

@ekse
Copy link
Collaborator

ekse commented Feb 9, 2018

I decided to make mem_map_ptr() unsafe,. If someone calls this function with a value of size that does not match unicorn will probably crash. There is nothing wrong with using mem_map_ptr and it doesn't change anything from a user perspective other than having to wrap the call inside an unsafe{} block.

I will go ahead and merge this change, I will also do an update of the package on crates.io.

@ekse
Copy link
Collaborator

ekse commented Feb 17, 2018

The package has been update to 0.8.0.

@ekse ekse closed this as completed Feb 17, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants