stuff that i want to see in or for esil

[condret]

• [x] esil.os config-var
• [ ] there must be hooks in esilcallbacks reserved for tracing and hooks reserved for platform voodo custom
• [ ] explicit regprofiles in analplugins (don't expect the one from the debugger to be the correct choice for your emulation)
• [ ] more interrupt-handlers for x86, that depend on esil.os and anal.bits
• [ ] api to register syscalls, so we can hook them instead of hooking the interrupts for catching the syscalls
• [ ] fork-syscall (requires the 2 previous points)
  • [ ] clearing the question how brk-syscall could/should work in esil
  • [ ] switching between multiple esil-instances that have memory and reg-stats associated to them (this will cause a shitload of bugs, i think)
• [ ] redefining stuff with RLang
• [ ] open and load libs on aei
• [ ] Hook a native handler for esil to a specific pc=ADDR
• [ ] close those libs on esil-fini
• [ ] more people interested in esil
  • [ ] Write an article on the blog explaining how to use ESIL

[radare]

Why esil.os? we already have asm.os, i would prefer to merge those concepts as much as possible to avoid duplicated variables in several places of r2. like the problem we have right now with asm/anal/.. to change bits/arch not unified.

[radare]

Those native handlers are required to be implemented as a layer of abstraction between esil and the bare metal. Those handlers must pop the values from the stack or read the registers to construct call the function and then return back those values to the esil world.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Considering a lot has changed since its creation, we kindly ask you to check again if the issue you reported is still relevant in the current version of radare2. If it is, update this issue with a comment, otherwise it will be automatically closed if no further activity occurs. Thank you for your contributions.

[condret]

"Why esil.os? we already have asm.os, i would prefer to merge those concepts as much as possible to avoid duplicated variables in several places of r2. like the problem we have right now with asm/anal/.. to change bits/arch not unified." - uhm, I actually don't remember why that esil-os at all. If user sets up interrupt and syscall handlers there should be no need for this anyway.

[condret]

"Those native handlers are required to be implemented as a layer of abstraction between esil and the bare metal" - not only that, in some cases they could be bending the functionality into libr. so if a target opens a file, we should be able to open that in RIO and pass the desc's fd back. If a target uses mmap we must (wouldn't work otherwise) use r_io_map to instead, so that the user can manipulate the mapping later on.