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 <
lld
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* call
Please do submit this for review, yes.
> On May 11, 2016, at 1:27 PM, Philippe Lavoie
> wrote:
>
> Thanks for the explanation and the patch.
>
> I tried it and the exception is gone.
> The debug info also seems complete. As complete as can be for an LTO build...
>
> I attached a modified patc
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
GetL
We have a way internally with:
virtual Error
lldb_private::Process::GetMemoryRegionInfo (lldb::addr_t load_addr,
MemoryRegionInfo &range_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
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 have
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 rem
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 Net
