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" <gclay...@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 <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
