llvm-svn: 183139

Thanks to Daniel and valgrind.

llvm-svn: 183110

All running threads will be detected and stopped on attach and all threads get resumed on detach.

llvm-svn: 183049

- as per review comment from Dimitry Andric!

llvm-svn: 183039

Patch by Ed Maste!

llvm-svn: 183038

Add 'JoinExistingSession' to XPC for root debugging.

llvm-svn: 183037

- 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

<rdar://problem/14005311>

llvm-svn: 183022

Making sure that I get my English right by saying “0 bytes” instead

llvm-svn: 182978

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

Cleaned up the thread updating code in the OperatingSystemPython class. It doesn't need to clear the "new_thread_list" anymore as it is always empty. 

It also now assigns the "core_thread_list" to "new_thread_list" if no threads are detected through python.

llvm-svn: 182893

llvm-svn: 182892

condition doesn't return a result, instead
of blindly trying to use that result.

<rdar://problem/14009519>

llvm-svn: 182875

llvm-svn: 182873

Adding support for stopping all threads of multithreaded inferiors on Linux.  Also adding multithreaded test cases.

llvm-svn: 182809

Giving a timeout for the call to NSPrintForDebugger() that happens when you “po” objects

This is a temporary workaround until a more detailed solution to the general problem of canceling actions is found

llvm-svn: 182782

- This resolves the remaining issues related to building lldb utility/dylib
- TODO: fix up debugserver build

Patch by Ahmed Bougacha!

llvm-svn: 182751

llvm-svn: 182687

llvm-svn: 182683

Scalar now can make itself signed if needed.

<rdar://problem/13977632>

llvm-svn: 182668

which takes a first step towards symbolization of disassembled instructions.

llvm-svn: 182650

Fixed performance issues that arose after changing SBTarget, SBProcess, SBThread and SBFrame over to using a std::shared_ptr to a ExecutionContextRef. The ExecutionContextRef doesn't store a std::weak_ptr to a stack frame because stack frames often get replaced with new version, so it held onto a StackID object that would allow us to ask the thread each time for the frame for the StackID. The linear function was too slow for large recursive stacks. We also fixed an issue where anytime the std::shared_ptr<ExecutionContextRef> in any SBTarget, SBProcess, SBThread objects was turned into an ExecutionContext object, it would try to resolve all items in the ExecutionContext which are shared pointers. Even if the StackID in the ExecutionContextRef was invalid, it was looking through all frames in every thread. This causes a lot of unnecessary frame accesses.

llvm-svn: 182627

llvm-svn: 182619

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

llvm-svn: 182540

llvm-svn: 182538

llvm-svn: 182537

Added logging for the OS plug-in python objects in OperatingSystemPython so we can see the python dictionary returned from the plug-in when logging is enabled.

llvm-svn: 182530

live as long as they needed to.  This led to
equality tests involving persistent variables
often failing or succeeding when they had no
business doing so.

To do this, I introduced the ability for a
memory allocation to "leak" - that is, to
persist in the process beyond the lifetime of
the expression.  Hand-declared persistent
variables do this now.

<rdar://problem/13956311>

llvm-svn: 182528

Fixed ProcessMachCore to be able to locate the main executeable in the core file even if it doesn't start at a core file address range boundary. Prior to this we only checked the first bytes of each range in the core file for mach_kernel or dyld. Now we still do this, but if we don't find the mach_kernel or dyld anywhere, we go through all core file ranges and check every 0x1000 to see if we can find dyld or the mach_kernel.

Now that we can properly detect the mach_kernel at any address, we don't need to call "DynamicLoaderDarwinKernel::SearchForDarwinKernel(Process*)" anymore.

llvm-svn: 182513

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

Another fix to make sure that if we aren't able to extract an object file for any reason, we don't crash when trying to parse the debug map info.

llvm-svn: 182441

lldb crashes with universal file containing skinny BSD archives when doing DWARF with .o file debugging.

llvm-svn: 182437

llvm-svn: 182434

Added a test case that verifies that LLDB can debug across a process exec'ing itself into a new program. This currently is only enabled for Darwin since we exec from 64 bit to 32 bit and vice versa for 'x86_64' targets.

This can easily be adapted for linux and other platforms, but I didn't want to break any buildbots by assuming it will work.

llvm-svn: 182428

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