[lldb-dev] Reading memory while inferior is running

[Mario Zechner]

This is excellent news. I assume your refer to the Python script i posted
in [1]. That was a port of our production code to illustrate issues with
high frequency process suspends/resumes in conjunction with tracing
steps/breakpoints.

If reading from the inferiors memory while the process is running works,
then that issues will vanish.

We are targeting Mac OS X and iOS, both of which use debugserver and hence
GDBProcess afaik. Does GDBProcess support reading memory while the process
is running?

Thanks,
Mario

[1] http://lists.cs.uiuc.edu/pipermail/lldb-dev/2014-December/006138.html
On Jan 6, 2015 11:08 PM, "Greg Clayton" <gclayton at apple.com> wrote:

> 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 <badlogicgames at 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 at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150106/e196de3b/attachment.html>