Drop the old f registers from debugserver's register list. Add the
NEON 128-bit q registers to debugserver, support reading and writing.
Add the new contains / invalidates mappings for the s, d, and q
registers so lldb will know what registers overlay what other registers.
Change the default format of s and d registers to be floating point
instead of hex. Remove some UTF-8 hyphen chars in comments in the ARM
register number definition headers.
<rdar://problem/13121797>
llvm-svn: 176915
uninitialized memory, to getTrivialTypeSourceInfo,
which initializes its memory, when creating trivial
TypeSourceInfos.
<rdar://problem/13332253>
llvm-svn: 176899
As much as I hate to leave this hacky code in that adds some d and q registers to ARM registers, I must leave it in.
The code is now fixed to not just assume ANY arm target will have registers in a certain order. We now verify the common regs are the same name and byte size before adding the d and q regs.
llvm-svn: 176752
This is a very basic implementation of a library that easily allows to drive LLDB.framework to write test cases for performance
This is separate from the LLDB testsuite in test/ in that:
a) this uses C++ instead of Python to avoid measures being affected by SWIG
b) this is in very early development and needs lots of tweaking before it can be considered functionally complete
c) this is not meant to test correctness but to help catch performance regressions
There is a sample application built against the library (in darwin/sketch) that uses the famous sample app Sketch as an inferior to measure certain basic parameters of LLDB's behavior.
The resulting output is a PLIST much like the following:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
<dict>
<key>fetch-frames</key>
<real>0.13161715522222225</real>
</dict>
<dict>
<key>file-line-bkpt</key>
<real>0.029111678750000002</real>
</dict>
<dict>
<key>fetch-modules</key>
<real>0.00026376766666666668</real>
</dict>
<dict>
<key>fetch-vars</key>
<real>0.17820429311111111</real>
</dict>
<dict>
<key>run-expr</key>
<real>0.029676525769230768</real>
</dict>
</array>
</plist>
Areas for improvement:
- code cleanups (I will be out of the office for a couple days this coming week, but please keep ideas coming!)
- more metrics and test cases
- better error checking
This toolkit also comprises a simple event-loop-driven controller for LLDB, similar yet much simpler to what the Driver does to implement the lldb command-line tool.
llvm-svn: 176715
counters for a variety of metrics associated
with expression parsing. This should give some
idea of how much work the expression parser is
doing on Clang's behalf, and help with hopefully
reducing that load over time.
<rdar://problem/13210748> Audit type search/import for expressions
llvm-svn: 176714
Make dynamic type detection faster by using the AST metadata to help out and allow us not to complete types when we don't need to.
After running "purge" on a MacOSX system, the Xcode variables view now populates more than 3x faster with this fix.
llvm-svn: 176676
- change string "ERROR" to "FAIL" to match clang lit test results
Also, make LLDB tests work on machines that do not have svn and/or git installed
llvm-svn: 176633
"compile_units" returns an array of all compile units in a module as a list() of lldb.SBCompileUnit objects.
"compile_unit" returns a compile unit accessor object that allows indexed access, search by full or partial path, or by regex:
(lldb) script
comp_unit = lldb.target.module['TextEdit'].compile_unit['Document.m']
comp_unit = lldb.target.module['TextEdit'].compile_unit['/path/to/Document.m']
comp_unit = lldb.target.module['TextEdit'].compile_unit[0]
comp_unit = lldb.target.module['TextEdit'].compile_unit[1]
for comp_unit in lldb.target.module['TextEdit'].compile_unit[re.compile("\.m$")]
print comp_unit
This helps do quick searches and scripting while debugging.
llvm-svn: 176613
I used this to verify that the debug map line tables were the same as previous LLDB releases prior to my change in the DWARF in .o file linking.
llvm-svn: 176610
- missing definitions were causing different definitions of type 'off_t', resulting in linker errors
- fix is to define _LARGEFILE_SOURCE and _FILE_OFFSET_BITS=64
llvm-svn: 176595
The test was marked as expectedFailureLinux, but now it passes with gcc and some versions of clang. Newer versions of clang introduce a failure due to bad DWARF information.
llvm-svn: 176581
Also added C++11 enum test cases to cover enums as int8_t, int16_t int32_t, int64_t, uint8_t, uint16_t, uint32_t, and uint64_t both for DWARF and dSYM cases. The DWARF being emitted by clang is missing the enum integer type, but the code is now ready to accept and deal with the integral type if it is supplied.
llvm-svn: 176548
LLDB wasn't printing the names for negative enums. Fixed the signed extraction of enumerators and how they were registered with clang's type system.
llvm-svn: 176533
- resolved circular dependency issue by making liblldb depend directly on LLDBWrapPython.cpp
- removed use of '..' for relative directories -- ninja doesn't like this
- fixed build-order problem
llvm-svn: 176517
DWARF with .o files now uses 40-60% less memory!
Big fixes include:
- Change line table internal representation to contain "file addresses". Since each line table is owned by a compile unit that is owned by a module, it makes address translation into lldb_private::Address easy to do when needed.
- Removed linked address members/methods from lldb_private::Section and lldb_private::Address
- lldb_private::LineTable can now relink itself using a FileRangeMap to make it easier to re-link line tables in the future
- Added ObjectFile::ClearSymtab() so that we can get rid of the object file symbol tables after we parse them once since they are not needed and kept memory allocated for no reason
- Moved the m_sections_ap (std::auto_ptr to section list) and m_symtab_ap (std::auto_ptr to the lldb_private::Symtab) out of each of the ObjectFile subclasses and put it into lldb_private::ObjectFile.
- Changed how the debug map is parsed and stored to be able to:
- Lazily parse the debug map for each object file
- not require the address map for a .o file until debug information is linked for a .o file
llvm-svn: 176454
Make it configurable what to profile.
For Mac, we don't use the dirty page size yet and hence there is no need to gather that. This should be way better in not draining the battery since we are operating between 0% to 0.1% on the Mac after this change.
llvm-svn: 176451
in a core file if it didn't start at the beginning of a memory segment.
I added more sophisticated kernel location code to DynamicLoaderDarwinKernel
and removed the simple one in ProcessMachCore. Unfortunately the kernel
DynamicLoader doesn't get a chance to search around in memory unless there's
a hint that this might be a kernel debug session. It was easy ot make the
kernel location code static in DynamicLoaderDarwinKernel and call it from
ProcessMachCore on the start of the session, so that's what I did.
<rdar://problem/13326647>
llvm-svn: 176405
Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.
<rdar://problem/11319574>
<rdar://problem/9329275>
llvm-svn: 176392
and use it to keep from doing the OS Plugin UpdateThreadList while destroying, since
if that does anything that requires the API lock it may deadlock against whoever is
running the Process::Destroy.
<rdar://problem/13308627>
llvm-svn: 176375
Also removed the use of llvm::raw_string_ostream as it wasn't needed.
Also fixed a crasher that could occur when the following line returned a C string tied to a local variable:
return OS.str().c_str();
I am guessing "static std::string buf;" was supposed to get assigned to "OS.str()" and then have "buf.c_str()" returned.
Modified the non-apple version code to cache its value and not recompute the version every time.
llvm-svn: 176274
- make LLDB version number match Clang (and the Debian package)
- use the same revision detection magic that Clang uses to report SVN/Git revisions
- update test case as per above
Example output:
$ lldb -v
lldb version 3.3 (https://dmalea@llvm.org/svn/llvm-project/lldb/trunk revision 176211 clang revision 176208 llvm revision 176208)
ss
This line, and those below, will be ignored--
M source/lldb.cpp
M test/help/TestHelp.py
M source/Makefile
llvm-svn: 176268
- made sure we tell Clang not to try to
complete the type since it can't be
completed from its origin any more; and
- fixed a silly bug where we tried to
forget about the original decl's origins
rather than the deported decl's origin.
These produced some crashes in ptr_refs,
especially under libgmalloc.
<rdar://problem/13256150>
llvm-svn: 176233
in the Process destructor. Doing it there can be too late depending on what the internal state
and ProcessGDBRemote Async threads are doing.
<rdar://problem/13297536>
llvm-svn: 176203
binary to lldb already check that the UUID of that binary and the UUID of
the kernel binary in memory match. Warn if they don't.
<rdar://problem/13184784>
llvm-svn: 176160
Categories were conceptually meant to be placeable on test methods as well as test classes and test directories
However, that was broken. This checkin fixes that.
The incantation required to put categories on individual test case methods is not exactly elegant, unfortunately:
def test_case(self):
"""Test me."""
self.do_it()
def _test_case_get_categories(self):
return ["demo"]
test_case.getCategories = _test_case_get_categories
del _test_case_get_categories
llvm-svn: 176158
Fixed an issue with clang 500's new way to represent static class variables where it emits a DW_TAG_member with a DW_AT_external(0x01) attribute and no DW_AT_data_member_location.
llvm-svn: 176140
SymbolFileDWARF code:
- If a class is being uniqued to another copy of itself
and the method lists don't match exactly, take a slow
path and at least unique the methods that they have
in common.
- Sort name_to_die maps before querying them. This
would otherwise result in uniquing failures because
looking up a name in a map that contains it would
often fail.
- Tolerate classes in other symbol files in the case
of debugging with .o files rather than with a
.dSYM. We used to assume that the classes being
uniqued were in the same symbol file, causing
unpredictable results.
This will dramatically reduce the number of cases where
a function does not have a valid DeclContext.
<rdar://problem/12153915>
llvm-svn: 176067
plugin.dynamic-loader.darwin-kernel.load-kexts setting, don't print
any messages about loading the kexts (which isn't being done) and
don't read the Mach-O headers out of memory (which can be slow and
they're not being used for anything at this point).
llvm-svn: 176064
Remove the getCategory from TestDataFormatterObjC.py, since it was superceded by the .categories file,
and didn't work anyway (getCategories currently has to be a method on the test class, not on the test.)
Add a "basic_process" category, and start to find some tests for simple process running sniff tests.
llvm-svn: 176061
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.
llvm-svn: 175953
The decorators @expectedFailure (plain and special-case like i386, clang, ...) are modified to optionally take a bugnumber argument
If such an argument is specified, the failure report (or unexpected success report) will include the information passed in as part of the message
This is mostly useful for associating failures to issue IDs in issue management systems (e.g. the LLVM bugzilla)
llvm-svn: 175942
Fixed an issue where if we got a 'A' async packet back from debugserver, we would resend the last continue command. We now correctly identify the packet as async (just like the 'O' stdout async packet) and we don't resend the continue command.
llvm-svn: 175924
own port namepsace) as the thread identifier to using the system-wide
globally unique thread id as the thread identifier number.
MachThread.cpp keeps both the unique id and the mach port number
for each thread. All layers outside MachThread class use the unique
id with three exceptions: (1) Mach exceptions come in with the port
number (thread_port) which needs to be translated, (2) any calls to
low-level thread_get_state/thread_set_state/thread_suspend etc need
to use the mach port number, (3) MachThreadList::UpdateThreadList
which creates the MachThread objects gets the unique id and passes
it to the MachThread ctor as an argument.
In general, any time nub_thread_t is used, it is now referring to a
unique thread id. Any time a thread_t is used, it is now referring
to a mach port number. There was some interchangability of these
types previously. nub_thread_t has also been changed to a 64-bit
type which necessitated some printf specification string changes.
I haven't been able to test these changes extensively yet but want
to checkpoint the work. The scenarios I've been testing are all
working correctly so while there may be some corner cases I haven't
hit yet, I think it is substantially correct.
<rdar://problem/12931414>
llvm-svn: 175870
- replace "catch-all" except clause with one that specifically catches what pexpect throws
- handle case where child is already terminated (or is terminating) by the time tear-down is run
llvm-svn: 175844
The notion of Crossref command has long been forgotten, and there is nothing using CommandObjectCrossref in the current LLDB codebase
However, this was causing a conflict with process plugins and command aliases ending up in an infinite loop under situations such as:
(lldb) command alias monitor process plugin packet monitor
(lldb) process att -n Calendar
Process 28709 stopped
Executable module set to "/Applications/Calendar.app/Contents/MacOS/Calendar".
Architecture set to: x86_64-apple-macosx.
(lldb) command alias monitor process plugin packet monitor
This fixes the loop (and consequent crash) by disposing of Crossref commands and related code
llvm-svn: 175831
On x86-64 platforms, the small code model assumes that code will be loaded below the 2GB boundary. With the static relocation model, the fact that the expression code is initially loaded (in the LLDB debugger address space) above that boundary causes problems. Switching to the JITDefault code model causes the large code model to be used for 64-bit targets and small code model of 32-bit targets.
llvm-svn: 175828
Jim Ingham