It is fine to not require that a process be stopped in order to read memory.
Are you still doing your python based approach? We are currently enforcing that
a process must be stopped in order to read memory in SBProcess::ReadMemory()
where we acquire the run lock and make sure the process stays stopped. This can
be changed, but we will probably need to add code the lldb_private::Process
that asks the current process if it can handle reading memory while running.
So the code would need to go from this:
if (process_sp)
{
Process::StopLocker stop_locker;
if (stop_locker.TryLock(&process_sp->GetRunLock()))
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
bytes_read = process_sp->ReadMemory (addr, dst, dst_len,
sb_error.ref());
}
else
{
if (log)
log->Printf ("SBProcess(%p)::ReadMemory() => error: process is
running",
static_cast<void*>(process_sp.get()));
sb_error.SetErrorString("process is running");
}
}
to something like:
if (process_sp)
{
Process::StopLocker stop_locker;
if (process_sp->CanReadMemoryWhileRunning() ||
stop_locker.TryLock(&process_sp->GetRunLock()))
{
Mutex::Locker api_locker (process_sp->GetTarget().GetAPIMutex());
bytes_read = process_sp->ReadMemory (addr, dst, dst_len,
sb_error.ref());
}
else
{
if (log)
log->Printf ("SBProcess(%p)::ReadMemory() => error: process is
running",
static_cast<void*>(process_sp.get()));
sb_error.SetErrorString("process is running");
}
}
The lldb_private::Process::CanReadMemoryWhileRunning() would need to be a
virtual function that is added to lldb_private::Process which defaults to
return false. Then any process plug-ins that do allow this can override this
function and return true.
Greg
> On Dec 21, 2014, at 6:28 AM, Mario Zechner <badlogicga...@gmail.com> wrote:
>
> Hi,
>
> i know this has been asked before [1], but i just wanted to explore whether
> it's a waste of time to patch this into our LLDB fork. I talked about our
> architecture in [2]. It boils down to having to suspend/resume the inferior
> to quickly read a tiny bit of memory. This causes us quite a bit of problems
> as outlined in the other thread.
>
> Our memory reads would be just that: fetch a block of memory from a known,
> non-stack address. We can resolve atomicity issues on our end. Do you think
> this would be feasible?
>
> Thanks,
> Mario
>
>
> [1] http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-June/004139.html
> [2] http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-December/006138.html
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
