Re: [lldb-dev] Standalone build broken after r269332
Hi Eugene,
my thoughts on this are inline.
On 14 May 2016 at 01:46, Eugene Zelenko via lldb-dev
wrote:
> Hi!
>
> I tried to build standalone LLDB after r269332 change in
> LLDBStandalone.cmake and encountered next problems:
>
> It implies that LLVM and Clang were built separately, but they could
> be built together, so next changes should be made as in previous
> version:
>
> -
> include("${LLVM_OBJ_ROOT}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang/ClangConfig.cmake")
> + if (EXISTS
> "${LLVM_OBJ_ROOT}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang/ClangConfig.cmake")
> +
> include("${LLVM_OBJ_ROOT}/lib${LLVM_LIBDIR_SUFFIX}/cmake/clang/ClangConfig.cmake")
> + endif()
This part makes sense. I don't like the "IF EXISTS" part that much,
but if there is no other reasonable way to test for "IF
LLVM_AND_CLANG_BUILT_TOGETHER", then that's fine. Here we have to
diverge from clang standalone build as it does not need to depend on
clang as well as llvm.
>
> Include path for generated LLVM headers were not added, so I made next tweak:
>
> - include_directories("${LLVM_BINARY_DIR}/include"
> "${LLVM_MAIN_INCLUDE_DIR}")
> + include_directories("${LLVM_OBJ_ROOT}/include"
> "${LLVM_BINARY_DIR}/include" "${LLVM_MAIN_INCLUDE_DIR}")
Sounds reasonable as well (although it might be interesting to check
out how come clang does not need this fix as well).
>
> But biggest problem remains is how to specify Clang source and build
> directories, since llvm-config doesn't tells about them.
>
> Previously I set next variables, but situation may be different when
> LLVM and Clang are built separately:
>
> -DLLDB_PATH_TO_CLANG_BUILD=${LLVMBuildDir}/tools/clang
> -DLLDB_PATH_TO_CLANG_SOURCE=${LLVMSourceDir}/tools/clang
> -DLLDB_PATH_TO_LLVM_BUILD=${LLVMBuildDir}
> -DLLDB_PATH_TO_LLVM_SOURCE=${LLVMSourceDir}
>
At which stage does the build now fail for you (after applying the
fixes above)?
As Kamil said, LLDB really shouldn't depend on the clang source
folder. The only dependency I know of is the uglyness in lldb-mi, but
it looks like it should be easy to fix (basically, lldb-mi should use
the public regex interface instead of the private one, porting
appeared straight-forward), so I think someone should just bite the
bullet and do it. If you need any more changes after that, we can look
into that then.
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Listing memory regions in 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 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. This is what I see: 0xffef 0xfffe 0x0010 (1,048,576) RW0x 0x 0x0001 (65,536) 0x0001 0x07ff7713 0x07fe7714 (8,789,500,887,040) 0x07ff7714 0x07ff7714bfff 0xc000 (49,152) R 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 make any difference. Howard HellyerIBM Runtime Technologies, IBM Systems - Original message -From: Adrian McCarthy To: Howard Hellyer/UK/IBM@IBMGBCc: Greg Clayton , LLDB Subject: Re: [lldb-dev] Listing memory regions in lldbDate: Fri, May 13, 2016 4:57 PM Interestingly when I've worked on Windows core dumps before I've seen that MiniDump, with the right flags, will deliberately insert a region in the middle of the memory ranges to represent the unmapped space, on 64 bit it's quite a large section. Are you saying that's a bug in the minidump itself or in LLDB's handling of it? If the latter, please send me the details (e.g., which flags trigger this behavior), and I'll see what I can do about it. Adrian. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Listing memory regions in lldb
Apologies for the confusion, 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 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. This is what I see (from a random dump of no special importance!): 0xffef 0xfffe 0x0010 (1,048,576) RW 0x 0x 0x0001 (65,536) 0x0001 0x07ff7713 0x07fe7714 (8,789,500,887,040) 0x07ff7714 0x07ff7714bfff 0xc000 (49,152) R 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. 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-dev] Listing memory regions in lldb > > Interestingly when I've worked on Windows core dumps before I've > seen that MiniDump, with the right flags, will deliberately insert a > region in the middle of the memory ranges to represent the unmapped > space, on 64 bit it's quite a large section. > > Are you saying that's a bug in the minidump itself or in LLDB's > handling of it? If the latter, please send me the details (e.g., > which flags trigger this behavior), and I'll see what I can do about it. > > Adrian. > > On Fri, May 13, 2016 at 3:35 AM, Howard Hellyer via lldb-dev d...@lists.llvm.org> wrote: > I have experimented with the GetMemoryRegionInfo approach on the > internal APIs already, it has some positives and negatives. > > - GetMemoryRegionInfo is unimplemented for Linux and Mac core dumps. > That's not necessarily a bad thing as it could be implemented the > "right" way. (As Jim said GetMemoryRegionInfo would have to return > the right thing for an unmapped region.) Interestingly when I've > worked on Windows core dumps before I've seen that MiniDump, with > the right flags, will deliberately insert a region in the middle of > the memory ranges to represent the unmapped space, on 64 bit it's > quite a large section. > > - Using GetMemoryRegionInfo to iterate might be quite expensive if > there are many small memory regions. > > - One reason I hadn't looked at just exposing an > SBGetMemoryRegionInfo is that it wouldn't match a lot of the SB > API's at the moment (for example for Threads and Sections) which > tend work by having GetNumXs() and GetXAtIndex() calls. Iterating > with SBGetMemoryRegionInfo would be non-obvious to the user of the > API since it doesn't match the convention. It would need to be > documented in the SBGetMemoryRegionInfo API. > > - I've found the only way to reliably filter out inaccessible memory > is to do a test read and check the error return code. I'm pretty > sure I've seen some that are readable via a memory read but marked > read=false, write=false, execute=false. (I can't remember the exact > case now off the top of my head, but I think it might have been > allocated but uncommitted memory or similar.) > > - Using GetMemoryRegionInfo over a remote connection on Linux and > Mac worked well but seemed to coalesce some of the memory regions > together. It also only allows for read/write/exec attributes to be > passed. That's a shame as a live process can often tell you more > about what the region is for. The remote command memory map looks > like it sends back XML so it might be possible to insert custom > properties in there to give more information but I'm not sure how > safe it is to do that, I don't know the project quite well enough to > understand all the use cases for the protocol. > > - Extended infomation /proc/pid/maps marking a region as [stack] > would be lost. All you would get is read/write/exec info. (That said > supporting everything every platform can provide might be a bit much.) > > - LLDB's ReadMemory implementations seem to return 0's for missing > memory that should be accessible. It might be nice to include > whether the memory is backed by real data or not in the API. (For > example Linux core files can be missing huge pages depending on the > setting of /proc/PID/coredump_filter or files can simply be truncated.) > > I could implement the GetMemoryRegionInfo iteration mechanism pretty > quickly and it would actually fit my purposes as far as providing > all the addr
Re: [lldb-dev] Push work-in-progress plugin for Process NetBSD?
Provided it builds everywhere and you are planning on continuing to work on it, I see no problems with putting this into the lldb tree. If there are any parts that touch common code, you might want to submit those first (in appropriate chunks) so that the people who are going to review it can see the parts that touch their areas more clearly, then add in the independent code when the groundwork is settled. Jim > On May 12, 2016, at 6:28 PM, Zachary Turner via lldb-dev > wrote: > > 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 > wrote: > 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 removed unsupported features, missing > in the current version of NetBSD. > > It will be easier for me to keep it in sync with HEAD and should be > usable for other teams to take it into account in further changes. > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Listing memory regions in lldb
> 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 different implementations when one os/architecture has a better way of > doing it. This would fall out naturally if the gathering of the data is done in debugserver/lldb-server, which seems to me the natural place for this work to be done. Jim > > On Thu, May 12, 2016 at 11:09 AM Jim Ingham via lldb-dev > wrote: > 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 GetLoadBaseAddress, so you can distinguish the loaded and unloaded ones. > So you shouldn't need "readelf --segments" or "otool -l", lldb should know > this. > > You can scan the currently active stacks, but we don't currently know the > allocated stack extents, just what is being used. It would be interesting to > know the actual stack extents, so you could search in old stacks and to know > if you are close to exhausting the stack of a thread. > > We don't have either a generic API, or internal implementations, for getting > all the mapped memory regions (or shared pages) of processes. That would be > quite useful. IIRC ptr_refs does this by injecting some code into the target > program that enumerates the regions. Greg would know more about this. Most > systems provide some API to get at this that works cross-process, but that > doesn't help debugging remotely. So we either need to teach debugserver & > lldb-server to do this, or use appropriate code injection. The gdb-remote > protocol has a query for the "memory map" of the process, though this is more > tailored to identify things like memory mapped registers. Still it might be > possible to use this as well. > > It would be nice to be able to separately query heap, executable & stack > memory as well. Though a properly annotated memory map would give you a way > to do this, so that could be layered on top. > > Jim > > > On May 12, 2016, at 6:20 AM, Howard Hellyer via lldb-dev > > wrote: > > > > 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* calls will return an error on an invalid address but it's > > not an efficient way to scan a 64 bit address space. > > > > This seems like it blocks simple tasks like scanning memory for blocks > > allocated with a header and footer to track down memory leaks, which is > > crude but traditional, and ought to be pretty quick to script via the > > Python API. > > > > At the moment I've resorted to running a python script prior to launching > > my plugin that takes the output of "readelf --segments", /proc//maps > > or "otool -l" but this isn't ideal. On the assumption that I'm not missing > > something huge I've looked at whether it is possible to extend LLDB to > > provide this functionality and it seems possible, there are checks > > protecting calls to read memory that use the data that would need to be > > exposed. I'm working on a prototype implementation which I'd like to > > deliver back at some stage but before I go too far does this sound like a > > good idea? > > Howard Hellyer > > IBM Runtime Technologies, IBM Systems > > > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27782] New: Go tests failing on OS X
https://llvm.org/bugs/show_bug.cgi?id=27782
Bug ID: 27782
Summary: Go tests failing on OS X
Product: lldb
Version: unspecified
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified
The Go language tests are failing on OS X when using Xcode 7.3.1 and the latest
go from OS X homebrew (go1.6.2 darwin/amd64).
=
Issue Details
=
FAIL: test_dsym (functionalities/exec/TestExec.py)
FAIL: test_dwarf (functionalities/exec/TestExec.py)
FAIL: test_go_formatter_plugin (lang/go/formatters/TestGoFormatters.py)
FAIL: test_with_dsym_and_python_api (lang/go/types/TestGoASTContext.py)
FAIL: test_with_dsym_and_python_api_dsym
(lang/go/expressions/TestExpressions.py)
FAIL: test_with_dsym_and_python_api_dwarf
(lang/go/expressions/TestExpressions.py)
Session logs for test failures/errors/unexpected successes will go into
directory '2016-05-16-13_23_06'
Command invoked: /Users/tfiala/src/lldb-llvm.org-ci/lldb/test/dotest.py
--apple-sdk macosx
--executable=/Users/tfiala/src/lldb-llvm.org-ci/lldb/build/Release/lldb -C
/Users/tfiala/src/lldb-llvm.org-ci/lldb/llvm-build/Release+Asserts/x86_64/bin/clang
--rerun-all-issues --env TERM=vt100 -s 2016-05-16-13_23_06 --results-port 60612
--inferior -p TestGoASTContext.py
/Users/tfiala/src/lldb-llvm.org-ci/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=0:int
Configuration: arch=x86_64
compiler=/Users/tfiala/src/lldb-llvm.org-ci/lldb/llvm-build/Release+Asserts/x86_64/bin/clang
--
Collected 1 test
==
FAIL: test_with_dsym_and_python_api (TestGoASTContext.TestGoASTContext)
Test GoASTContext dwarf parsing.
--
Traceback (most recent call last):
File
"/Users/tfiala/src/lldb-llvm.org-ci/lldb/packages/Python/lldbsuite/test/decorators.py",
line 121, in wrapper
func(*args, **kwargs)
File
"/Users/tfiala/src/lldb-llvm.org-ci/lldb/packages/Python/lldbsuite/test/decorators.py",
line 270, in wrapper
return func(self, *args, **kwargs)
File
"/Users/tfiala/src/lldb-llvm.org-ci/lldb/packages/Python/lldbsuite/test/decorators.py",
line 121, in wrapper
func(*args, **kwargs)
File
"/Users/tfiala/src/lldb-llvm.org-ci/lldb/packages/Python/lldbsuite/test/lang/go/types/TestGoASTContext.py",
line 27, in test_with_dsym_and_python_api
self.check_main_vars()
File
"/Users/tfiala/src/lldb-llvm.org-ci/lldb/packages/Python/lldbsuite/test/lang/go/types/TestGoASTContext.py",
line 95, in check_main_vars
self.assertEqual('true', v.value)
AssertionError: 'true' != 'false'
Config=x86_64-/Users/tfiala/src/lldb-llvm.org-ci/lldb/llvm-build/Release+Asserts/x86_64/bin/clang-3.9
--
Ran 1 test in 1.917s
RESULT: FAILED (0 passes, 1 failures, 0 errors, 0 skipped, 0 expected failures,
0 unexpected successes)
Session logs for test failures/errors/unexpected successes can be found in
directory '2016-05-16-13_23_06'
[TestGoASTContext.py FAILED]
Command invoked: /usr/bin/python
/Users/tfiala/src/lldb-llvm.org-ci/lldb/test/dotest.py --apple-sdk macosx
--executable=/Users/tfiala/src/lldb-llvm.org-ci/lldb/build/Release/lldb -C
/Users/tfiala/src/lldb-llvm.org-ci/lldb/llvm-build/Release+Asserts/x86_64/bin/clang
--rerun-all-issues --env TERM=vt100 -s 2016-05-16-13_23_06 --results-port 60612
--inferior -p TestGoASTContext.py
/Users/tfiala/src/lldb-llvm.org-ci/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=0:int
1 out of 4 test suites processed - TestGoASTContext.py
Session logs for test failures/errors/unexpected successes will go into
directory '2016-05-16-13_23_06'
Command invoked: /Users/tfiala/src/lldb-llvm.org-ci/lldb/test/dotest.py
--apple-sdk macosx
--executable=/Users/tfiala/src/lldb-llvm.org-ci/lldb/build/Release/lldb -C
/Users/tfiala/src/lldb-llvm.org-ci/lldb/llvm-build/Release+Asserts/x86_64/bin/clang
--rerun-all-issues --env TERM=vt100 -s 2016-05-16-13_23_06 --results-port 60612
--inferior -p TestExec.py
/Users/tfiala/src/lldb-llvm.org-ci/lldb/packages/Python/lldbsuite/test
--event-add-entries worker_index=0:int
Configuration: arch=x86_64
compiler=/Users/tfiala/src/lldb-llvm.org-ci/lldb/llvm-build/Release+Asserts/x86_64/bin/clang
--
Collected 2 tests
==
FAIL: test_dsym (TestExec.ExecTestCase)
--
Traceback (most recent call last):
File
"/Users/tfiala/src/lldb-llv
Re: [lldb-dev] How to use command regex in this situation?
Regular expression commands are not multi-line commands. So your approach of doing: (lldb) command regex jspatch 's/(.+)/p (id)[JPEngine evaluateScript:@"%1"]/' won't work with: jspatch 'var a = 10 var b = 20 a = a + b' because this will get executed as: (lldb) jspatch 'var a = 10 (lldb) var b = 20 (lldb) a = a + b' You can run this as: (lldb) jspatch 'var a = 10; var b = 20; a = a+b;' Can't you? Or you might be able to put newlines in as escaped sequences: (lldb) jspatch 'var a = 10\nvar b = 20\na = a+b' The best thing you can probably do is write this as a python command. See http://lldb.llvm.org/python-reference.html in the section named "CREATE A NEW LLDB COMMAND USING A PYTHON FUNCTION". This will allow you to make a new command line command that calls into a python module and runs the code. You can use the builtin "raw_input" command to fetch as many lines as you need and then run the expression from python as needed. > On May 12, 2016, at 4:04 AM, Karl Peng via lldb-dev > wrote: > > Actually I posted a question in stackoverflow? > > Can any one give me some suggestion? > > Thanks > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] No C++ SB API for Watchpoint callbacks?
We just haven't gotten to it yet. If you implement this, please do it like we
do the breakpoints.
Greg Clayton
> On May 13, 2016, at 11:34 AM, Daniel Noland via lldb-dev
> wrote:
>
> Please correct me if I have missed something critical here, but the C++
> SB API does not seem to provide a way to set callbacks to run when a
> watchpoint is hit (while SBBreakpoint and the private Watchpoint class
> does offer this functionality).
>
> * Is this omission by design?
> * Is there another way to get similar functionality?
> * Would it be a good idea for me to contribute code which adds this
> functionality?
>
> I read through some of the source code, and I think it would be quite
> possible to add callback functionality in a manor nearly identical to
> the SBBreakpoint implementation.
>
> I have briefly started putting together the needed changes, but I
> thought I would check here to make sure I am solving a real problem in a
> good way before I go too far.
>
> Thanks,
> \author{Daniel Noland}
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Listing memory regions in lldb
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 possible. More
comments below.
> On May 13, 2016, at 3:35 AM, Howard Hellyer wrote:
>
> I have experimented with the GetMemoryRegionInfo approach on the internal
> APIs already, it has some positives and negatives.
>
> - GetMemoryRegionInfo is unimplemented for Linux and Mac core dumps. That's
> not necessarily a bad thing as it could be implemented the "right" way. (As
> Jim said GetMemoryRegionInfo would have to return the right thing for an
> unmapped region.) Interestingly when I've worked on Windows core dumps before
> I've seen that MiniDump, with the right flags, will deliberately insert a
> region in the middle of the memory ranges to represent the unmapped space, on
> 64 bit it's quite a large section.
this is very easy to implement as the there are just sections that say "these
bytes are for [0x1-0x11000)". I know Mach-o core files on Mac can
get the read/write/execute permissions. You can figure out the gaps very easily
as well in mach-o. So this shouldn't be a problem for core files. If the core
file is smart enough to say "here is the full map of what was in memory, but
the sections only describe part of the actual memory", then we should be able
to work with this still.
>
> - 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 iteration scheme, feel free to do so, but please
leave the call that ask about a single address intact so it can be used by
clients
> - One reason I hadn't looked at just exposing an SBGetMemoryRegionInfo is
> that it wouldn't match a lot of the SB API's at the moment (for example for
> Threads and Sections) which tend work by having GetNumXs() and GetXAtIndex()
> calls. Iterating with SBGetMemoryRegionInfo would be non-obvious to the user
> of the API since it doesn't match the convention. It would need to be
> documented in the SBGetMemoryRegionInfo API.
I don't think that the design of SBMemoryRegionInfo is affected by which
approach we take. If we can ask about a single address with:
SBError
SBTarget::GetMemoryRegionInfo(lldb::addr_t load_addr, SBMemoryRegionInfo
®ion_info);
Or if we have:
uint32_t
SBTarget::GetNumMemoryRegions();
bool
SBTarget::GetMemoryRegionAtIndex(uint32_t idx, SBMemoryRegionInfo ®ion_info);
It still doesn't change SBMemoryRegionInfo's definition. I don't like the above
two calls because if you do something bad like:
const uint32_t num_regions = target.GetNumMemoryRegions();
target.GetProcess().Continue();
...
SBMemoryRegionInfo region_info;
for (uint32_t i=0; i
> - I've found the only way to reliably filter out inaccessible memory is to do
> a test read and check the error return code. I'm pretty sure I've seen some
> that are readable via a memory read but marked read=false, write=false,
> execute=false. (I can't remember the exact case now off the top of my head,
> but I think it might have been allocated but uncommitted memory or similar.)
MacOSX knows this, but each process plug-in can do what it needs to in order to
determine this.
>
> - Using GetMemoryRegionInfo over a remote connection on Linux and Mac worked
> well but seemed to coalesce some of the memory regions together.
You might want to add an extra parameter to not coalesce regions. Or if we
start adding names to the memory regions (".text", ".data") or types (stack,
heap, section from a file, guard page) then we might just start not coalescing
the regions so we can see these differences. Or we can add more options to the
API:
SBMemoryRegionInfoList SBTarget::GetMemoryRegions(bool coalesce);
> It also only allows for read/write/exec attributes to be passed. That's a
> shame as a live process can often tell you more about what the region is for.
> The remote command memory map looks like it sends back XML so it might be
> possible to insert custom properties in there to give more information but
> I'm not sure how safe it is to do that, I don't know the project quite well
> enough to understand all the use cases for the protocol.
We can easily add names to regions and it would be ok for a region to not have
a name. We can also add types as a enumeration (stack, heap, section from a
file, guard page).
>
> - Extended infomation /proc/pid/maps marking a region as [stack] would be
> lost. All you would get is read/write/exec info. (That said supporting
> everything every platform can provide might be a bit much.)
>
> - LLDB's ReadMemory implementations seem to return 0'
Re: [lldb-dev] Standalone build broken after r269332
Hi, Pavel! On Mon, May 16, 2016 at 3:04 AM, Pavel Labath wrote: > Hi Eugene, > > my thoughts on this are inline. > > At which stage does the build now fail for you (after applying the > fixes above)? Build failed at very beginning: source/lldb.cpp:19:10: fatal error: 'clang/Basic/Version.h' file not found But there are much more places which depends on Clang headers (AST, Basic). > As Kamil said, LLDB really shouldn't depend on the clang source > folder. The only dependency I know of is the uglyness in lldb-mi, but > it looks like it should be easy to fix (basically, lldb-mi should use > the public regex interface instead of the private one, porting > appeared straight-forward), so I think someone should just bite the > bullet and do it. If you need any more changes after that, we can look > into that then. I build LLVM/Clang/ect with LLVM_INSTALL_TOOLCHAIN_ONLY=ON, so source and build directories are needed for headers and libraries. I try to save disc space for final installation and we don't use LLVM/Clang headers/libraries internally, so source and build directories were good enough for us. Eugene. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
