Make sure the selected platform is always used
Make sure that the host uses the connect://hostname to connect to both
the lldb-platform and the lldb-gdbserver rather than what the platform
reports as the hostname of the lldb-gdbserver
Make sure that lldb-platform uses the IP address on it's connection
back to the host instead of the hostname that the host sends to it
when launching lldb-gdbserver with the remote host information
Tested on OSX and Linux
llvm-svn: 226712
The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918
and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb
llvm-svn: 226199
This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address.
This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name.
The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups.
<rdar://problem/18945678>
llvm-svn: 226084
step through the complete function looking for any epilogue
instructions. If we find an epilogue sequence, re-instate
the correct unwind instructions if there is more code past
that epilogue -- this will correctly handle an x86 function
with multiple epilogues in it.
NB there is still a bug with the "eh_frame augmented"
UnwindPlans and mid-function epilogues. Looking at that next.
<rdar://problem/18863406>
llvm-svn: 225770
section for x86_64 and i386 targets on Darwin systems. Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it. The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them. There may need to be some bug fixing over the next couple weeks as
I exercise and test it further. But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837>
llvm-svn: 223625
(e.g. breakpoints, stop-hooks) before we have any targets - for instance in
your ~/.lldbinit file. These will then get copied over to any new targets
that get created. So far, you can only make stop-hooks.
Breakpoints will have to learn to move themselves from target to target for
us to get them from no-target to new-target.
We should also make a command & SB API way to prime this ur-target.
llvm-svn: 222600
is treated as a string instead of a FileSpec.
OptionValueFileSpec::SetValueFromCString() passes the c string to
FileSpec::SetFile(str, true /* resolve */) - and with Zachary's
changes to FileSpec we're using llvm::sys::fs::make_absolute() to
do that "resolve" action now, where we used to use realpath().
One important difference between llvm::sys::fs::make_absolute and
realpath is that when they're handed a filename (no directory),
realpath prepends the current working directory *and if the file exists*,
returns that full path. If that file doesn't exist, the caller
uses the basename only.
llvm::sys::fs::make_absolute prepends the current working directory
regardless of whether it exists or not.
I considered having FileSpec::SetFile save the initial pathname,
call FileSpec::Resolve, and then check to see if the Resolve return
path exists - and if not, go back to the original one.
But instead I just went with changing 'target modules load' to treat its
filename argument as a string instead of a FileSpec. This brings it
in line with how 'target modules list' works.
<rdar://problem/18955416>
llvm-svn: 222498
We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not.
But for x86 & x86_64 compiler generated code:
1. clang & GCC describes all prologue instructions in eh_frame;
2. mid-function stack pointer altering instructions can be easily detected.
So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table.
This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them.
Change by Tong Shen.
llvm-svn: 216406
Fixes include:
1 - added new FileSpec method: bool FileSpec::Readable()
2 - detect when an executable is not readable and give an appropriate error for:
(lldb) file /tmp/unreadablefile
3 - detect when a core file is not readable and give an appropriate error
4 - detect when a specified core file doesn't exist and give an appropriate error
<rdar://problem/17727734>
llvm-svn: 215741
This reverses out the options validators changes. We'll get these
back in once the changes to the output can be resolved.
Restores broken tests on FreeBSD, Linux, MacOSX.
Changes reverted: r212500, r212317, r212290.
llvm-svn: 212543
The purpose of the OptionValidator is to determine, based on some
arbitrary set of conditions, whether or not a command option is
valid for a given debugger state. An example of this might be
to selectively disable or enable certain command options that
don't apply to a particular platform.
This patch contains no functional change, and does not actually
make use of an OptionValidator for any purpose yet. A follow-up
patch will begin to add the logic and users of OptionValidator.
Reviewed by: Greg Clayton, Jim Ingham
Differential Revision: http://reviews.llvm.org/D4369
llvm-svn: 212290
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
Multichar constants are not portable as the byte order is undefined. Use a
constant value instead. This avoids a warning when compiling with gcc 4.8+
(-Wmultichar) and makes the code more portable.
llvm-svn: 204110
ObjectFile::SetLoadAddress (Target &target,
lldb::addr_t value,
bool value_is_offset);
Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides.
Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing.
Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file.
llvm-svn: 201003
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
<rdar://problem/15314403>
This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future.
llvm-svn: 196557
iterators for LLDB's container data structures.
Iterable abstracts over the backing data structure,
ignoring keys for maps for example. It also provides
locking as a service so that the code
for (ThreadSP thread_sp : process->Threads())
{
// ... use thread_sp
}
takes the appropriate locks once, without having to
do anything else.
The salient advantages of this system are:
- Much simpler and idiomatic loop code
- Lock once instead of each time an element is fetched
- Less boilerplate to produce the iterators
The intent is that Iterable will replace Get...AtIndex
in most places, and that ForEach(), which solves the
same problem in a less-idiomatic way, be phased out in
favor of this approach.
I've added Iterables to ThreadList, TypeList, and
Process (which is really just forwarding to ThreadList).
llvm-svn: 194159
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
DumpValueObject() 2.0
This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command:
- expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull)
When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in
(lldb) expr -O -v -- foo
(id) $0 = 0x000000010010baf0 {
1 = 2;
2 = 3;
}
When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in
(lldb) expr -O -- foo
{
1 = 2;
2 = 3;
}
- for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display
(lldb) po 5
5
-v also works in this mode
(lldb) expr -O -vfull -- 5
(int) $4 = 5
On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future
DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed
Test case to follow
llvm-svn: 191694
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
- 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
- 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 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
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
Fixed "target symbols add" to correctly extract all module specifications from a dSYM file that is supplied and match the symbol file to a current target module using the UUID values if they are available.
This fixes the case where you add a dSYM file (like "foo.dSYM") which is for a renamed executable (like "bar"). In our case it was "mach_kernel.dSYM" which didn't match "mach_kernel.sys".
llvm-svn: 181916
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
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
unwind instructions for a function/symbol which contains that
address.
Update the unwind_diagnose.py script to use this instead of doing
image show-unwind by name to avoid cases where there are multiple
name definitions.
llvm-svn: 180079
Introducing a negative cache for ObjCLanguageRuntime::LookupInCompleteClassCache()
This helps speed up the (common) case of us looking for classes that are hidden deep within Cocoa internals and repeatedly failing at finding type information for them.
In order for this to work, we need to clean this cache whenever debug information is added. A new symbols loaded event is added that is triggered with add-dsym (before modules loaded would be triggered for both adding modules and adding symbols).
Interested parties can register for this event. Internally, we make sure to clean the negative cache whenever symbols are added.
Lastly, ClassDescriptor::IsTagged() has been refactored to GetTaggedPointerInfo() that also (optionally) returns info and value bits. In this way, data formatters can share tagged pointer code instead of duplicating the required arithmetic.
llvm-svn: 178897
