Oh well, you win some, you lose some :) I was expecting that to be the case. At least i don't have to go down that rabbit hole with this info in hand.
Thanks! Mario On Jan 7, 2015 12:19 AM, "Greg Clayton" <gclay...@apple.com> wrote: > > > On Jan 6, 2015, at 2:58 PM, Mario Zechner <badlogicga...@gmail.com> > wrote: > > > > 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? > > Unfortunately no, not as it is currently coded. There is a "non-stop mode" > that the GDB remote protocol allows, but we don't currently support that in > our ProcessGDBRemote.cpp. I am not sure how much work it would be to > convert over to using this but this would allow for memory to be read while > things are running. Currently the GDB remote protocol can only send one > packet at a time, including when running the process, so you send a > continue packet and the response will be a stop reply packet, so the only > way to currently send a memory read is to interrupt the packet by sending a > CTRL+C (0x03 byte) which stops the target, then you can send the memory > read, and then resume the target. That probably won't improve things. > > So feel free to look into supporting the non-stop mode if you want. One > thing to note is that any existing iOS devices out there with previously > released developer support have a fixed developer disk image that has the > "debugserver" binary hard coded on it and they will never change, so we > have no hopes of adding non-stop mode to any previously released Xcode > tools. > > > > > > 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
