- as per review comment from Dimitry Andric!

llvm-svn: 183039

- missing #include <cstdlib> in Mangled.cpp
- missing include dirs in FreeBSD CMakeLists.txt

Patch by Ed Maste!

llvm-svn: 183032

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

llvm-svn: 183024

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

llvm-svn: 182892

Scalar now can make itself signed if needed.

<rdar://problem/13977632>

llvm-svn: 182668

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

Make sure to not call "regexec" from <regex.h> with a NULL C string, otherwise we can crash.

llvm-svn: 182607

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

llvm-svn: 182434

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

Thanks to Greg Clayton for catching this

llvm-svn: 182339

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

Correctly handle the case of a ValueObjectVariable backed by a Vector

llvm-svn: 182330

Replacing an assertion with an error - at least we won’t crash

llvm-svn: 182326

llvm-svn: 182325

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

Allow LLDB to be built on a system with an installed gcc/g++ that isn't the default. I recently installed gcc-4.7/g++-4.7 on Ubuntu and tried to build by specifying:

CC=gcc-4.7 CXX=g++-4.7

as configure and make args, but it didn't work when being run with makefiles. This patch fixes that.

llvm-svn: 182158

llvm-svn: 181911

llvm-svn: 181876

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

llvm-svn: 181218

Most important was a new[] + delete mismatch in ScanFormatDescriptor()
and a couple of possible memory leaks in FileSpec::EnumerateDirectory().

llvm-svn: 181080

UUID string in; added UUID::GetAsString() which returns the uuid string in
a std::string.  Updated callers to use the new method.

llvm-svn: 181078

This was causing a bunch of test cases to fail in python_api/process since they relied on SBValue::GetLocation()

llvm-svn: 181075

<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

Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules:

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

If a register is in a ValueObject, be sure to print its children if it is a vector type.

llvm-svn: 180237

Don't print the type if there is none and don't print "<invalid type>". ValueObjects can be register sets and register groups and dumping those with:

(lldb) script print frame.GetRegisters()

llvm-svn: 180236

Added the ability to extract a ModuleSpecList (a new class) from an ObjectFile. This is designed to be used when you have an object file that contains one or more architectures (MacOSX universal (fat) files) and/or one or more objects (BSD archive (.a files)).

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

“plugin load” tries to be more helpful when it fails to load a plugin

llvm-svn: 180218

- avoid deadlocks if Broadcaster::SignUpListenersForBroadcaster and
  Listener::StartListeningForEventSpec are both called concurrently

llvm-svn: 180050

llvm-svn: 180047