with prefer_file_cache == false. This is what we want to do when
the user is doing a disassemble command -- show the actual memory
contents in case the memory has been corrupted or something -- but
when we're profiling functions for stepping or unwinding
(ThreadPlanStepRange::GetInstructionsForAddress,
UnwindAssemblyInstEmulation::GetNonCallSiteUnwindP) we can read
__TEXT instructions directly out of the file, if it exists.
<rdar://problem/14397491>
llvm-svn: 190638
This allows the PC to be directly changed to a different line.
It's similar to the example python script in examples/python/jump.py, except implemented as a builtin.
Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function)
llvm-svn: 190572
SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb
This checkin converts that sample script to a C++ provider built into LLDB
A test case is also provided
llvm-svn: 190564
Since I renamed most of the LLVM Mach-O enums in r189314, I had to go fix
LLDB to use the new names. While I was here, I decided that a COFF
plugin really shouldn't be using Mach-O enums.
llvm-svn: 189316
Summary:
This merge brings in the improved 'platform' command that knows how to
interface with remote machines; that is, query OS/kernel information, push
and pull files, run shell commands, etc... and implementation for the new
communication packets that back that interface, at least on Darwin based
operating systems via the POSIXPlatform class. Linux support is coming soon.
Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS
X Mountain Lion.
Additional improvements (not in the source SVN branch 'lldb-platform-work'):
- cmake build scripts for lldb-platform
- cleanup test suite
- documentation stub for qPlatform_RunCommand
- use log class instead of printf() directly
- reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely.
- add new logging category 'platform'
Reviewers: Matt Kopec, Greg Clayton
Review: http://llvm-reviews.chandlerc.com/D1493
llvm-svn: 189295
This means that "register read stmm0 --format f" actually works now.
This is a little messy but LLDB assumes 'long double' is portable, when it is not.
llvm-svn: 188698
address.
When loading a dSYM, and the file addresses of the dSYM Sections are
different than the executable binary Sections' file addresses, the
debug info won't be remapped to the actual load addresses correctly.
This only happens with binaries on the in-memory shared cache binaries
where their File addresses have been set to their actual load address
(outside an offset value) whereas the original executable and dSYM
have 0-based File addresses.
I think this patch will not be activated for other cases -- this is
the only case we know of where the dSYM and the executable's File
addresses differ -- but if this causes other problems we can restrict
it more carefully.
<rdar://problem/12335086>
llvm-svn: 188532
LLDB needs in memory module load level settings to control how much information is read from memory when loading in memory modules. This change adds a new setting:
(lldb) settings set target.memory-module-load-level [minimal|partial|complete]
minimal will load only sections (no symbols, or function bounds via function starts or EH frame)
partial will load sections + bounds
complete will load sections + bounds + symbols
llvm-svn: 188246
list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this
for real when I have time to do so.
<rdar://problem/14581918>
llvm-svn: 187473
ELF notes contain a 'name' field, which specifies a vendor who defines
the format of the note. Examples are 'FreeBSD' or 'GNU', or it may be
empty for generic notes.
Add a case for FreeBSD-specific notes, leaving Linux and GNU notes,
other vendor-specific notes, and generic notes to be handled by the
existing code for now.
Thanks to Samuel Jacob for reviewing and suggesting improvements.
llvm-svn: 186973
Added a setting to control timeout for kdp response packets. While I was at it, I also added a way to control the response timeout for gdb-remote packets.
KDP defaults to 5 seconds, and GDB defaults to 1 second. These were the default values that were in the code prior to adding these settings.
(lldb) settings set plugin.process.gdb-remote.packet-timeout 10
(lldb) settings set plugin.process.kdp-remote.packet-timeout 10
llvm-svn: 186360
- MachO files now correctly extract the UUID all the time
- More file size and offset verification done for universal mach-o files to watch for truncated files
- ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files)
- lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file
- The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback
- Improved printing for ModuleSpec objects
llvm-svn: 186211
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags
- Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections.
Other cleanups:
- Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly
- Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently
- Modified the Symtab class to store a file address lookup table for more efficient lookups
- Removed Section::Finalize() and SectionList::Finalize() as they did nothing
- Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs
- Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement)
llvm-svn: 185990
There are two new classes:
lldb::SBModuleSpec
lldb::SBModuleSpecList
The SBModuleSpec wraps up a lldb_private::ModuleSpec, and SBModuleSpecList wraps up a lldb_private::ModuleSpecList.
llvm-svn: 185877
Both StopReadThread and the thread being stopped set the thread id to
0 after m_read_thread_enabled was set to false. If the thread being
stopped got there first then StopReadThread called pthread_join on an
invalid thread number. This is not a Good Thing,
Should fix a fairly regular segfault when quitting on Linux.
llvm-svn: 185107
Specifically, the ${target ${process ${thread and ${frame specifiers have been extended to allow a subkeyword .script:<fctName> (e.g. ${frame.script:FooFunction})
The functions are prototyped as
def FooFunction(Object,unused)
where object is of the respective SB-type (SBTarget for target.script, ... and so on)
This has not been implemented for ${var because it would be akin to a Python summary which is already well-defined in LLDB
llvm-svn: 184500
The script was able to point out and save 40 bytes in each lldb_private::Section by being very careful where we need to have virtual destructors and also by re-ordering members.
llvm-svn: 184364
Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*"
Also, a couple improvements to the "lldb types" logging
llvm-svn: 184215
325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote.
That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly.
Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed.
llvm-svn: 183820
Modified the test programs to use floating point constants that always will display correctly. We had some numbers that were being rounded, and now that we are using clang, we no longer round them and we get more correct results.
llvm-svn: 183792
Add support for half-floats, as specified by IEEE-754-2008
With this checkin, you can now say:
(lldb) x/7hf foo
to read 7 half-floats at address foo
llvm-svn: 183716
level. Fixes a bug in "break set --source-pattern-regexp" when a shared library is
specified.
Also cleaned up the help text for --source-pattern-regexp so it is a little clearer.
<rdar://problem/14084261>
llvm-svn: 183476
Fixing an issue where formats would not propagate from parents to children in all cases
Details follow:
an SBValue has children and those are fetched along with their values
Now, one calls SBValue::SetFormat() on the parent
Technically, the format choices should propagate onto the children (see ValueObject::GetFormat())
But if the children values are already fetched, they won't notice the format change and won't update themselves
This commit fixes that by making ValueObject::GetValueAsCString() check if any format change intervened from the previous call to the current one
A test case is also added
llvm-svn: 183030
command script import now does reloads - for real
If you invoke command script import foo and it detects that foo has already been imported, it will
- invoke reload(foo) to reload the module in Python
- re-invoke foo.__lldb_init_module
This second step is necessary to ensure that LLDB does not keep cached copies of any formatter, command, ... that the module is providing
Usual caveats with Python imports persist. Among these:
- if you have objects lurking around, reloading the module won't magically update them to reflect changes
- if module A imports module B, reloading A won't reload B
These are Python-specific issues independent of LLDB that would require more extensive design work
The --allow-reload (-r) option is maintained for compatibility with existing scripts, but is clearly documented as redundant - reloading is always enabled whether you use it or not
llvm-svn: 182977
Which means "platform process list" should work and list the architecture.
We are now parsing the elf build-id if it exists, which should allow us to load stripped symbols (looking at that next).
llvm-svn: 182610
settings set use-color [false|true]
settings set prompt "${ansi.bold}${ansi.fg.green}(lldb)${ansi.normal} "
also "--no-use-colors" on the command prompt
llvm-svn: 182609
Lock the lldb_private::Module mutex while tearing down the module to make sure we don't get clients accessing the contents on a module as it is going away.
llvm-svn: 182511
Yet another implementation of the python in dSYM autoload :)
This time we are going with a ternary setting:
true - load, do not warn
false - do not load, do not warn
warn - do not load, warn (default)
llvm-svn: 182414
There are two settings:
target.load-script-from-symbol-file is a boolean that says load or no load (default: false)
target.warn-on-script-from-symbol-file is also a boolean, it says whether you want to be warned when a script file is not loaded due to security (default: true)
the auto loading on change for target.load-script-from-symbol-file is preserved
llvm-svn: 182336
This changes the setting target.load-script-from-symbol-file to be a ternary enum value:
default (the default value) will NOT load the script files but will issue a warning suggesting workarounds
yes will load the script files
no will not load the script files AND will NOT issue any warning
if you change the setting value from default to yes, that will then cause the script files to be loaded
(the assumption is you didn't know about the setting, got a warning, and quickly want to remedy it)
if you have a settings set command for this in your lldbinit file, be sure to change "true" or "false" into an appropriate "yes" or "no" value
llvm-svn: 182323
Name matching was working inconsistently across many places in LLDB. Anyone doing name lookups where you want to look for all types of names should used "eFunctionNameTypeAuto" as the sole name type mask. This will ensure that we get consistent "lookup function by name" results. We had many function calls using as mask like "eFunctionNameTypeBase | eFunctionNameTypeFull | eFunctionNameTypeMethod | eFunctionNameTypeSelector". This was due to the function lookup by name evolving over time, but as it stands today, use eFunctionNameTypeAuto when you want general name lookups. Either ModuleList::FindFunctions() or Module::FindFunctions() will figure out the right kinds of names to lookup and remove the "eFunctionNameTypeAuto" and replace it with the exact subset of what the name can be.
This checkin also changes eFunctionNameTypeAny over to use eFunctionNameTypeAuto to reflect this.
llvm-svn: 182179
Provide a mechanism through which users can disable loading the Python scripts from dSYM files
This relies on a target setting: target.load-script-from-symbol-file which defaults to false ("do NOT load the script")
You need to set it to true before creating your target (or in your lldbinit file if you constantly rely on this feature) to allow the scripts to load
llvm-svn: 181709
<rdar://problem/13594769>
Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging
The plug-in interface changes:
Modified the lldb_private::PluginInterface class that all plug-ins inherit from:
Changed:
virtual const char * GetPluginName() = 0;
To:
virtual ConstString GetPluginName() = 0;
Removed:
virtual const char * GetShortPluginName() = 0;
- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.
llvm-svn: 181631
This commit changes the ${function.name-with-args} prompt keyword to also tackle structs
Previously, since aggregates have no values, this would show up as foo=(null)
This checkin changes that to instead print foo=(Foo at 0x123) (i.e. typename at address)
There are other potential choices here (summary, one-liner printout of all members, ...) and I would love to hear feedback about better options, if any
llvm-svn: 181462
Most important was a new[] + delete mismatch in ScanFormatDescriptor()
and a couple of possible memory leaks in FileSpec::EnumerateDirectory().
llvm-svn: 181080
<rdar://problem/13723772>
Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.
A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.
llvm-svn: 180886
UInts even if their contents were set as bytes.
This makes expressions using registers work
better, especially with core files.
<rdar://problem/13743427>
llvm-svn: 180810
Enabling LLDB to write to variables that are stored in registers
Previously, this would not work since the Value's Context loses the notion of the data being in a register
We now store an "original" context that comes out of DWARF parsing, and use that context's data when attempting a write
llvm-svn: 180803
std::string
Module::GetSpecificationDescription () const;
This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.
llvm-svn: 180717
There is a new static ObjectFile function you can call:
size_t
ObjectFile::GetModuleSpecifications (const FileSpec &file,
lldb::offset_t file_offset,
ModuleSpecList &specs)
This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question).
This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info.
llvm-svn: 180224
variables in the ValueObject code:
- Report an error if the variable does not have
a valid address.
- Return the contents of the data to GetData(),
even if the value is constant.
<rdar://problem/13690855>
llvm-svn: 179876
lets a ValueObject's contents be set from raw
data. This has certain limitations (notably,
registers can only be set to data that is as
large as the register) but will be useful for
the new Materializer.
I also exposed this interface through SBValue.
I have added a testcase that exercises various
special cases of SBValue::SetData().
llvm-svn: 179437
This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows.
This assumption is easy to prove wrong, however.
For instance, after ~10k runs through this loop:
struct node
{
int value;
node* child;
node (int x)
{
value = x;
child = nullptr;
}
};
int main ()
{
node root(1);
node* ptr = &root;
int j = 2;
while (1)
{
ptr->child = new node(j++);
ptr = ptr->child;
}
return 0;
}
the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it
This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies.
In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values).
While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..)
Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB.
llvm-svn: 179330
platform.plugin.darwin-kernel.kext-directories
platform.plugin.darwin-kernel.search-locally-for-kexts
and fix a few FileSpec handling issues for the kext-directories setting.
llvm-svn: 178920
Add two initial settings for the PlatformDarwinKernel plugin,
plugin.platform.darwin-kernel.search-locally-for-kexts [true|false]
plugin.platform.darwin-kernel.kext-directories [directory list]
llvm-svn: 178846
Jason Molenda