I think it's fine, but I'll let others comment on that too.
But i will say, if you do this, please make sure it's clang-formatted.
On Thu, May 12, 2016 at 6:23 PM Kamil Rytarowski via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> I keep locally almost 5k lines of code of the process plugin for
I keep locally almost 5k lines of code of the process plugin for NetBSD.
It's still not functional (there are bugs), but it has all or mostly all
of the code needed for amd64. Is it fine to push it upstream and
continue development against the version in-tree?
My code is based on FreeBSD with
Oh, that's a cute trick, but it relies on the not (at-least-to-me) obvious fact
that an address in an unmapped region will return the extents of the unmapped
region. For it to be useful, that needs to be a requirement of the API's
implementation.
It seems to me it would be much clearer to
We have a way internally with:
virtual Error
lldb_private::Process::GetMemoryRegionInfo (lldb::addr_t load_addr,
MemoryRegionInfo _info);
This isn't expose via the public API in lldb::SBProcess. If you want, you can
expose this. We would need to expose a SBMemoryRegionInfo and the call
You should be able to enumerate the memory that is occupied by loaded
executables, by getting the list of loaded Modules from the target, and iterate
through the all the Sections. The Sections know their loaded locations. I
assume all the mapped ones will return a valid load address from
I'm working on a plugin for lldb and need to scan the memory of a crashed
process. Using the API to read chunks of memory and scan (via
SBProcess::Read*) for what I'm looking for is easy but I haven't been able
to find a way to find which address ranges are accessible. The
SBProcess::Read*
We already use both std::mutex and std::condition_variable
in include/lldb/Utility/TaskPool.h for a while (since October) and nobody
complained about it so I think we can safely assume that all platform has
the necessary STL support.
On Wed, May 11, 2016 at 11:44 PM Greg Clayton via lldb-dev <
