<font size=3>Apologies for the confusion, I don't mean either of those.</font>
<br><font size=3> </font>
<br><font size=3>This was working on a debug tool for the IBM JVM. When
we added the <b>MiniDumpWithFullMemoryInfo</b> to our calls to <b>MiniDumpWriteDump</b> we
found it inserted blank ranges to keep the regions in the <b>MINIDUMP_MEMORY_INFO_LIST</b> structure
contiguous. I checked a dump just now and it has a 8 Tb region without
and access flags inserted in the middle, probably because of a gap in the
addresses the libraries were loaded at, but it hasn't added an enormous
one at the end.</font>
<br><font size=3> </font>
<br><font size=3>This is what I see (from a random dump of no special importance!):</font>
<p><font size=3>0x00000000ffef0000 0x00000000fffeffff 0x0000000000100000
(1,048,576)                RW<br>
0x00000000ffff0000 0x00000000ffffffff 0x0000000000010000 (65,536) 
                 <br>
0x0000000100000000 0x000007ff7713ffff 0x000007fe77140000 (8,789,500,887,040)
       <br>
0x000007ff77140000 0x000007ff7714bfff 0x000000000000c000 (49,152)  
                R</font>
<p>
<br><font size=3>I guess I was trying to ask whether the LLDB API would
report a region like that or not really but if we use the SBMemoryRegionInfo
iteration model it won't really matter - there would be an equivalent blank
one there anyway so it doesn't really make a difference.</font>
<br><font size=3> </font>
<table width=650 style="border-collapse:collapse;">
<tr height=8>
<td width=650 style="border-style:none none none none;border-color:#000000;border-width:0px 0px 0px 0px;padding:0px 0px;"><font size=3 color=#8f8f8f face="sans-serif"><b>Howard Hellyer</b></font><font size=1 face="sans-serif"><br>
IBM Runtime Technologies, IBM Systems</font></table>
<br>
<br>
<br><tt><font size=2>Adrian McCarthy <amccarth@google.com> wrote
on 13/05/2016 16:57:07:<br>
<br>
> From: Adrian McCarthy <amccarth@google.com></font></tt>
<br><tt><font size=2>> To: Howard Hellyer/UK/IBM@IBMGB</font></tt>
<br><tt><font size=2>> Cc: Greg Clayton <gclayton@apple.com>,
LLDB <lldb-dev@lists.llvm.org></font></tt>
<br><tt><font size=2>> Date: 13/05/2016 16:57</font></tt>
<br><tt><font size=2>> Subject: Re: [lldb-dev] Listing memory regions
in lldb</font></tt>
<br><tt><font size=2>> <br>
> Interestingly when I've worked on Windows core dumps before I've <br>
> seen that MiniDump, with the right flags, will deliberately insert
a<br>
> region in the middle of the memory ranges to represent the unmapped
<br>
> space, on 64 bit it's quite a large section.</font></tt>
<br><tt><font size=2>> <br>
> Are you saying that's a bug in the minidump itself or in LLDB's <br>
> handling of it?  If the latter, please send me the details (e.g.,
<br>
> which flags trigger this behavior), and I'll see what I can do about
it.</font></tt>
<br><tt><font size=2>> <br>
> Adrian.</font></tt>
<br><tt><font size=2>> <br>
> On Fri, May 13, 2016 at 3:35 AM, Howard Hellyer via lldb-dev <lldb-<br>
> dev@lists.llvm.org> wrote:</font></tt>
<br><tt><font size=2>> I have experimented with the GetMemoryRegionInfo
approach on the <br>
> internal APIs already, it has some positives and negatives. <br>
> <br>
> - GetMemoryRegionInfo is unimplemented for Linux and Mac core dumps.<br>
> That's not necessarily a bad thing as it could be implemented the
<br>
> "right" way. (As Jim said GetMemoryRegionInfo would have
to return <br>
> the right thing for an unmapped region.) Interestingly when I've <br>
> worked on Windows core dumps before I've seen that MiniDump, with
<br>
> the right flags, will deliberately insert a region in the middle of
<br>
> the memory ranges to represent the unmapped space, on 64 bit it's
<br>
> quite a large section. <br>
> <br>
> - Using GetMemoryRegionInfo to iterate might be quite expensive if
<br>
> there are many small memory regions. <br>
> <br>
> - One reason I hadn't looked at just exposing an <br>
> SBGetMemoryRegionInfo is that it wouldn't match a lot of the SB <br>
> API's at the moment (for example for Threads and Sections) which <br>
> tend work by having GetNumXs() and GetXAtIndex() calls. Iterating
<br>
> with SBGetMemoryRegionInfo would be non-obvious to the user of the
<br>
> API since it doesn't match the convention. It would need to be <br>
> documented in the SBGetMemoryRegionInfo API. <br>
> <br>
> - I've found the only way to reliably filter out inaccessible memory<br>
> is to do a test read and check the error return code. I'm pretty <br>
> sure I've seen some that are readable via a memory read but marked
<br>
> read=false, write=false, execute=false. (I can't remember the exact
<br>
> case now off the top of my head, but I think it might have been <br>
> allocated but uncommitted memory or similar.) <br>
> <br>
> - Using GetMemoryRegionInfo over a remote connection on Linux and
<br>
> Mac worked well but seemed to coalesce some of the memory regions
<br>
> together. It also only allows for read/write/exec attributes to be
<br>
> passed. That's a shame as a live process can often tell you more <br>
> about what the region is for. The remote command memory map looks
<br>
> like it sends back XML so it might be possible to insert custom <br>
> properties in there to give more information but I'm not sure how
<br>
> safe it is to do that, I don't know the project quite well enough
to<br>
> understand all the use cases for the protocol. <br>
> <br>
> - Extended infomation /proc/pid/maps marking a region as [stack] <br>
> would be lost. All you would get is read/write/exec info. (That said<br>
> supporting everything every platform can provide might be a bit much.)
<br>
> <br>
> - LLDB's ReadMemory implementations seem to return 0's for missing
<br>
> memory that should be accessible. It might be nice to include <br>
> whether the memory is backed by real data or not in the API. (For
<br>
> example Linux core files can be missing huge pages depending on the
<br>
> setting of /proc/PID/coredump_filter or files can simply be truncated.)
<br>
> <br>
> I could implement the GetMemoryRegionInfo iteration mechanism pretty<br>
> quickly and it would actually fit my purposes as far as providing
<br>
> all the addresses you can sensibly access. <br>
> <br>
> I'm quite keen to provide a patch but don't want to provide one that<br>
> is at odds with how the rest of lldb works or provides data that's
<br>
> only useful to me so I'm quite keen to get a bit of feedback on what<br>
> the preferred approach would be. It could be that providing both <br>
> SBGetMemoryRegionInfo and the SBGetNumMemoryRegions/<br>
> SBGetMemoryRegionAtIndex pair is the right solution. <br>
> <br>
> Would a patch also need to provide a command to dump this <br>
> information as it can be awkward to have data that's only accessible<br>
> via the API? <br>
</font></tt>
<br><tt><font size=2>> <br>
> Howard Hellyer<br>
> IBM Runtime Technologies, IBM Systems </font></tt>
<br><tt><font size=2>> <br>
> <br>
> <br>
> <br>
> Greg Clayton <gclayton@apple.com> wrote on 12/05/2016 19:09:49:<br>
> <br>
> > From: Greg Clayton <gclayton@apple.com> <br>
> > To: Howard Hellyer/UK/IBM@IBMGB <br>
> > Cc: lldb-dev@lists.llvm.org <br>
> > Date: 12/05/2016 19:10 <br>
> > Subject: Re: [lldb-dev] Listing memory regions in lldb </font></tt>
<br><tt><font size=2>> > <br>
> > We have a way internally with:<br>
> > <br>
> >     virtual Error<br>
> >     lldb_private::Process::GetMemoryRegionInfo (lldb::addr_t
<br>
> > load_addr, MemoryRegionInfo &range_info);<br>
> > <br>
> > This isn't expose via the public API in lldb::SBProcess. If you
<br>
> > want, you can expose this. We would need to expose a <br>
> > SBMemoryRegionInfo and the call could be:<br>
> > <br>
> > namespace lldb<br>
> > {<br>
> >     class SBProcess<br>
> >     {<br>
> >         SBError GetMemoryRegionInfo (lldb::addr_t
load_addr, <br>
> > SBMemoryRegionInfo &range_info);<br>
> >     };<br>
> > }<br>
> > <br>
> > then you would call this API with address zero and it would return
a<br>
> > SBMemoryRegionInfo with an address range and if that memory is
read/<br>
> > write/execute. On MacOSX we always have a page zero at address
0 for<br>
> > 64 bit apps so it would respond with:<br>
> > <br>
> > [0x0 - 0x100000000) read=false, write=false, execute=false<br>
> > <br>
> > Then you call the function again with the end address of the
<br>
> previous range. <br>
> > <br>
> > I would love to see this functionality exported through our public
<br>
> > API. Let me know if you are up for making a patch. If you are,
you <br>
> > might want to quickly read the following web page to see the
rules <br>
> > that we apply to anything going into our public API:<br>
> > <br>
> > </font></tt><a href="http://lldb.llvm.org/SB-api-coding-rules.html"><tt><font size=2>http://lldb.llvm.org/SB-api-coding-rules.html</font></tt></a><tt><font size=2><br>
> > <br>
> > <br>
> > Greg<br>
> > <br>
> > > On May 12, 2016, at 6:20 AM, Howard Hellyer via lldb-dev
<lldb-<br>
> > dev@lists.llvm.org> wrote:<br>
> > > <br>
> > > I'm working on a plugin for lldb and need to scan the memory
of a <br>
> > crashed process. Using the API to read chunks of memory and scan
<br>
> > (via SBProcess::Read*) for what I'm looking for is easy but I
<br>
> > haven't been able to find a way to find which address ranges
are <br>
> > accessible. The SBProcess::Read* calls will return an error on
an <br>
> > invalid address but it's not an efficient way to scan a 64 bit
<br>
> address space. <br>
> > > <br>
> > > This seems like it blocks simple tasks like scanning memory
for <br>
> > blocks allocated with a header and footer to track down memory
<br>
> > leaks, which is crude but traditional, and ought to be pretty
quick <br>
> > to script via the Python API. <br>
> > > <br>
> > > At the moment I've resorted to running a python script prior
to <br>
> > launching my plugin that takes the output of "readelf --segments",
/<br>
> > proc/<pid>/maps or "otool -l" but this isn't
ideal. On the <br>
> > assumption that I'm not missing something huge I've looked at
<br>
> > whether it is possible to extend LLDB to provide this functionality
<br>
> > and it seems possible, there are checks protecting calls to read
<br>
> > memory that use the data that would need to be exposed. I'm working
<br>
> > on a prototype implementation which I'd like to deliver back
at some<br>
> > stage but before I go too far does this sound like a good idea?
<br>
> > > Howard Hellyer<br>
> > > IBM Runtime Technologies, IBM Systems   <br>
> > > <br>
> > > <br>
> > > _______________________________________________<br>
> > > lldb-dev mailing list<br>
> > > lldb-dev@lists.llvm.org<br>
> > > </font></tt><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev"><tt><font size=2>http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</font></tt></a><tt><font size=2><br>
> > </font></tt>
<br><tt><font size=2>> <br>
> _______________________________________________<br>
> lldb-dev mailing list<br>
> lldb-dev@lists.llvm.org<br>
> </font></tt><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev"><tt><font size=2>http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</font></tt></a><tt><font size=2><br>
</font></tt>