[Bug] Initial "goto RIP" unset

[OdinVex]

Out of habit I tend to hit the asterisk key to 'goto RIP' but upon launching a process (with Initial Breakpoint set to Application Entry Point) EDB assumes 0 rather than getting RIP from the register itself. ("No Memory Found": "There appears to be no memory at that location (0x0000000000000000)"

[eteran]

Well that's interesting for sure. I'll take a look

[OdinVex]

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.

[eteran]

OK, the strange thing is that so far, I haven't been able to replicate this.

What I've done is:

1. open edb
2. Ensure that the initial breakpoint is set to Application Entry Point
3. File -> Open -> /bin/ls
4. hit '*' on my kayboard

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?

[eteran]

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.

[eteran]

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);
            });
        }
    }
}

[OdinVex]

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.)

[eteran]

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.

[OdinVex]

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.

[eteran]

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 :-)

[eteran]

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.

[OdinVex]

May re-open issue if I can follow-up, for now assuming "working as intended/unimplemented for now."