> On May 20, 2016, at 3:27 AM, Howard Hellyer wrote:
>
> >> - Using GetMemoryRegionInfo to iterate might be quite expensive if there
> >> are many small memory regions.
> >
> > Remember that the other use for GetMemoryRegionInfo() might be a user just
> > asking about an address they have in
>> - Using GetMemoryRegionInfo to iterate might be quite expensive if
there are many small memory regions.
>
> Remember that the other use for GetMemoryRegionInfo() might be a user
just asking about an address they have in a register or variable that is a
pointer. So if we do add a more complex
I am fine with adding new key/value pairs to each memory region so feel free to
extend as needed as long as any missing keys ("memory_type == stack" for
example) default to something sensible. Then each process plug-in can do what
it can do and the process plug-ins will fill in as much info as p
> On May 13, 2016, at 9:13 AM, Zachary Turner wrote:
>
> On Intel processors, the best way to do this is probably going to be to walk
> the page directory (see Intel processor manuals). Assuming someone
> implements this command in lldb, I hope it can be done in such a way as to
> allow diff
#x27;t really make a difference.
Howard Hellyer
IBM Runtime Technologies, IBM Systems
Adrian McCarthy wrote on 13/05/2016 16:57:07:
> From: Adrian McCarthy
> To: Howard Hellyer/UK/IBM@IBMGB
> Cc: Greg Clayton , LLDB
> Date: 13/05/2016 16:57
> Subject: Re: [lldb-
Apologies, I don't mean either of those.
This was working on a debug tool for the IBM JVM. When we added the MiniDumpWithFullMemoryInfo to our calls to MiniDumpWriteDump we found it inserted blank ranges to keep the regions in the MINIDUMP_MEMORY_INFO_LIST structure contiguous. I checked a dump j
On Intel processors, the best way to do this is probably going to be to
walk the page directory (see Intel processor manuals). Assuming someone
implements this command in lldb, I hope it can be done in such a way as to
allow different implementations when one os/architecture has a better way
of doi
lution.
>
> Would a patch also need to provide a command to dump this information as
> it can be awkward to have data that's only accessible via the API?
>
> *Howard Hellyer*
> IBM Runtime Technologies, IBM Systems
>
>
>
>
> Greg Clayton wrote on 12/05/2016 19:
9:09:49:
> From: Greg Clayton
> To: Howard Hellyer/UK/IBM@IBMGB
> Cc: lldb-dev@lists.llvm.org
> Date: 12/05/2016 19:10
> Subject: Re: [lldb-dev] Listing memory regions in lldb
>
> We have a way internally with:
>
> virtual Error
> lldb_private::Process::GetMemoryR
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
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
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
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
13 matches
Mail list logo
