edb-debugger icon indicating copy to clipboard operation
edb-debugger copied to clipboard

Run Until Return is very slow

Open 10110111 opened this issue 8 years ago • 6 comments

For a function with a long loop, Run Until Return appears too slow to be usable. At least one part of it seems to be the DebuggerCore::get_state() calls. Since the only thing which is used there is instruction pointer, it should take some shortcut: at least not query the extended states like SSE/AVX/etc., and at best use PTRACE_P{EEK,OKE}_USER.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

10110111 avatar May 16 '16 13:05 10110111

Actually this is very similar to #263, but is another case to check when it's fixed.

10110111 avatar May 16 '16 15:05 10110111

Yea, I imagine that it's two sides of the same coin. perhaps we should introduce a version of get_state that specifically only fills GPRs or something like that to make these type of operations faster?

eteran avatar May 16 '16 16:05 eteran

Hmm, I think this should first be benchmarked. I guess peek/poke would be still faster.

10110111 avatar May 16 '16 16:05 10110111

Yea, peek/poke would definitely be faster for simply running until EIP is at a location that disassembles to a ret. The difficulty is in trying to also support things like expression evaluation efficiently as well.

eteran avatar May 16 '16 17:05 eteran

For the special case of "Run until return", we may be able to get away with a very minimalist/fast approach.

Perhaps we could add to the thread API some sort of "PeekRegister" function that lets you directly ask for a specific register so things like this can be done cheaply.

eteran avatar May 16 '16 17:05 eteran

But specific register would mean comparison of strings I guess? That doesn't look too performant... For common things like instruction pointer I think special functions should be available. And for something more rarely used maybe a state cache would be a good idea.

10110111 avatar May 16 '16 18:05 10110111