A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;
Linux test suite passes just fine now.
<rdar://problem/21494354>
llvm-svn: 240702
* Add and fix the emulation of several instruction.
* Disable frame pointer usage on Android.
* Specify return address register for the unwind plan instead of explict
tracking the value of RA.
* Replace prologue detection heuristics (unreliable in several cases)
with a logic to follow the branch instructions and restore the CFI
value based on them. The target address for a branch should have the
same CFI as the source address (if they are in the same function).
* Handle symbols in ELF files where the symbol size is not specified
with calcualting their size based on the next symbol (already done
in MachO files).
* Fix architecture in FuncUnwinders with filling up the inforamtion
missing from the object file with the architecture of the target.
* Add code to read register wehn the value is set to "IsSame" as it
meanse the value of a register in the parent frame is the same as the
value in the current frame.
Differential revision: http://reviews.llvm.org/D10447
llvm-svn: 240533
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())
Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones
llvm-svn: 238286
This continues the effort to reduce header footprint and improve
build speed by removing clang and other unnecessary headers
from Target.h. In one case, some headers were included solely
for the purpose of declaring a nested class in Target, which was
not needed by anybody outside the class. In this case the
definition and implementation of the nested class were isolated
in the .cpp file so the header could be removed.
llvm-svn: 231107
A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit
As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging
It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable
SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value
rdar://problem/15539930
llvm-svn: 228791
./dotest.py -A x86_64 -C clang -v -t -f TestImageListMultiArchitecture.test_image_list_shows_multiple_architectures
The problem was that if the platform wasn't compatible with the current file in the "target create" command, it wasn't finding a platform that was like it used to.
Also, the currently selected platform was being used upload the file _before_ the target was created which was incorrect as "target create a.out" might switch platforms if its architecture doesn't match, so I moved the uploading to happen after the target was created so we use the right platform (the one in the target, not the selected one).
llvm-svn: 227380
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
ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose
The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code
This checkin provides one and only one (and hopefully correct :-) entry point for this conversion
llvm-svn: 178044
Replacing the address argument type with address-expression in cases where StringToAddress() is used, and hence an expression can be passed where previously only a numeric address was allowed
This makes the documentation more clear and helps users discover that they can truly pass in an expression in these situations.
llvm-svn: 173753
Flush the process when symbols are loaded/unloaded manually. This was going on in:
- "target modules load" command
- SBTarget::SetSectionLoadAddress(...)
- SBTarget::ClearSectionLoadAddress(...)
- SBTarget::SetModuleLoadAddress(...)
- SBTarget::ClearModuleLoadAddress(...)
llvm-svn: 173745
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
Fixed an issue with the auto loading of script resources in debug info files. Any platform can add support for this, and on MacOSX we allow dSYM files to contain python modules that get automatically loaded when a dSYM file is associated with an executable or shared library.
The modifications will now:
- Let the module locate the symbol file naturally instead of using a function that only works in certain cases. This helps us to locate the script resources as long as the dSYM file can be found.
- Don't try and do any of this if the script interpreter has scripting disabled.
- Allow more than one scripting resource to be found in a symbol file by returning the list
- Load the scripting resources when a symbol file is added via the "target symbols add" command.
- Be smarter about matching the dSYM mach-o file to an existing executable in the target images by stripping extensions on the symfile basname if needed.
llvm-svn: 172275
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like:
memory read <addr> [<end-addr>]
memory write <addr>
breakpoint set --address <addr>
disassemble --start-address <addr> --end-address <addr>
It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers.
llvm-svn: 169556
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)
Patch by Matt Kopec!
llvm-svn: 169341
Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite.
This fix does the following:
- make sure all short options are treated as "int"
- make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired
- fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates
- fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value
llvm-svn: 169189
For "target create" you can now specify "--no-dependents" to not track down and add all dependent shared libraries. This can be handy when doing manual symbolication. Also added the "--symfile" or "-s" for short so you can specify a module and a stand alone debug info file:
(lldb) target create --symfile /tmp/a.dSYM /usr/bin/a
Added the "--symfile" option to the "target modules add" for the same reason. These all help with manualy symbolication and expose functionality that was previously only available through the public API layer.
llvm-svn: 169023
Emit an error when using "target modules add PATH" where PATH points to a debug info only (dSYM) file.
Also added a "--uuid" option for "target modules add --uuid UUID" to locate and load a module by UUID if the host supports it.
llvm-svn: 168949
This commit does three things:
(a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions
whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress
(b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action
of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting
the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds
(c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment:
- the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself)
- if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine
llvm-svn: 167569
There was a generic catch-all type for path arguments
called "eArgTypePath," and a specialized version
called "eArgTypeFilename." It turns out all the
cases where we used eArgTypePath we could have
used Filename or we explicitly meant a directory.
I changed Path to DirectoryName, made it use the
directory completer, and rationalized the uses of
Path.
<rdar://problem/12559915>
llvm-svn: 166533
<rdar://problem/12068650>
More fixes to how we handle paths that are used to create a target.
This modification centralizes the location where and how what the user specifies gets resolved. Prior to this fix, the TargetList::CreateTarget variants took a FileSpec object which meant everyone had the opportunity to resolve the path their own way. Now both CreateTarget variants take a "const char *use_exe_path" which allows the TargetList::CreateTarget to centralize where the resolving happens and "do the right thing".
llvm-svn: 166186
LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:
target.arg0 (string) =
There is also the program argument that are separate from the first argument that have existed for a while:
target.run-args (arguments) =
When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
- resolved executable path
- argv0
- program args
Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.
llvm-svn: 166137
enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mistake of trying to obtain a mutex lock for the scope
of a code block by doing
Mutex::Locker(m_map_mutex);
This doesn't assign the lock object to a local variable; it is
a temporary that has its dtor called immediately. Instead,
Mutex::Locker locker(m_map_mutex);
does what is intended. For some reason -Wshadow happened to
highlight these as shadowed variables.
I also fixed a few obivous and easy shadowed variable issues
across the code base but there are a couple dozen more that
should be fixed when someone has a free minute.
<rdar://problem/12437585>
llvm-svn: 165269
We can now do:
Specify a path to a debug symbols file:
(lldb) add-dsym <path-to-dsym>
Go and download the dSYM file for the "libunc.dylib" module in your target:
(lldb) add-dsym --shlib libunc.dylib
Go and download the dSYM given a UUID:
(lldb) add-dsym --uuid <UUID>
Go and download the dSYM file for the current frame:
(lldb) add-dsym --frame
llvm-svn: 164806
Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform.
llvm-svn: 163676
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
'add-dsym' (aka 'target symbols add') should display error messages when dsym file is not found
or the dsym uuid does not match any existing modules. Add TestAddDsymCommand.py test file.
llvm-svn: 162332
Add an lldb command line option to specify a core file: --core/-c.
For consistency, change the "target create" command to also use --core.
llvm-svn: 161993
UnwindPlans for a function. This specifically does not use any
previously-generated UnwindPlans so if any logging is performed
while creating the UnwindPlans, it will be repeated. This is
useful for when an lldb stack trace is not correct and you want
to gather diagnostic information from the user -- they can do
log enable -v lldb unwind, image show-unwind of the function, and
you'll get the full logging as the UnwindPlans are recreated.
llvm-svn: 160095
Greg Clayton