Closed OdinVex closed 4 months ago
Well that's interesting for sure. I'll take a look
It seems that it'll return 0x0000000000000000
if the target process being stepped/"debugged". Eg. if just ran. It should attempt to determine RIP
, even if it'd seem useless. In short, if a process is attached it should attempt to find RIP
regardless of whether we're about to step or anything.
OK, the strange thing is that so far, I haven't been able to replicate this.
What I've done is:
Application Entry Point
So far, it usually looks like it does nothing, but really it's just already scrolled to the right place. If i scroll away and then hit '*' it works as expected.
Is there anything else I should be doing to reproduce the issue?
Also, worth noting that I'm testing with the latest build from master
, if you're testing with an older version, the bug may have already been fixed accidentally over time.
Notably, from the looks of it, it seems like the code is doing exactly what I'd want it to do:
void Debugger::mnuCPUJumpToEIP() {
if (IProcess *process = edb::v1::debugger_core->process()) {
if (std::shared_ptr<IThread> thread = process->currentThread()) {
State state;
thread->getState(&state);
followMemory(state.instructionPointer(), [](edb::address_t address) {
return edb::v1::jump_to_address(address);
});
}
}
}
I use the AUR build, it's currently at 1.5.4
. It was acting this way -at startup- yesterday but not today. *sigh* No idea why. However, it does not work if it's running. (Eg., no breakpoints, F9 run...press asterisk.)
1.5.4
? Hmm, they must be doing some numbering of their own, we only just did a 1.5.0
release like a week ago, LOL.
Anyway, the only thing I can think of is if somehow the internal state is not set, but that REALLY shouldn't happen.
edb::address_t State::instructionPointer() const {
if (impl_) {
return impl_->instructionPointer();
}
return edb::address_t(0);
}
I can say that for your last comment, yes, it is the expected behavior that many operations don't work if the process is currently in a running state.
I'm more for the Olly experience, so I'll probably either need to write a plugin or fork. It's very handy to find routines you may not know are being ran.
I'm more for the Olly experience, so I'll probably either need to write a plugin or fork. It's very handy to find routines you may not know are being ran.
I'd definitely be interesting in a patch if you know how to implement it. To my knowledge, a LOT of the ptrace
API expects the debuggee to be in a stopped state in order to read from it.
So to implement what you're talking about, I think we'd need to implement kinda of micro-pauses where if the debugger API tries to read data from a running thread/process, then it would stop the process, wait for the event, get/set the data, and finally, resume the thread all seemlessly without the user really noticing that it was paused.
Doable for sure, but may be complicated.
All that being said, I am currently brainstorming a rework of the event API anyway because there's a couple of circumstances I'd like it to be able to handle better. So we'll see what we come up with :-)
Note, that in principle, if you do know how to implement it with the ptrace API, then it should be as simple as updating the DebuggerCore
plugin. So let me know if you end up trying that.
May re-open issue if I can follow-up, for now assuming "working as intended/unimplemented for now."
Out of habit I tend to hit the
asterisk
key to 'gotoRIP
' but upon launching a process (withInitial Breakpoint
set toApplication Entry Point
) EDB assumes0
rather than gettingRIP
from the register itself. ("No Memory Found": "There appears to be no memory at that location (0x0000000000000000)"