Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression.

llvm-svn: 182066

Implement ObjectFileELF::GetModuleSpecifications(), and add PlatformLinux code to deal with unknown arch properties.

CR: Greg Clayton
llvm-svn: 182065

llvm-svn: 182064

llvm-svn: 182061

llvm-svn: 182060

Note in the documentation about the fact that Python callbacks can return a value and if that value is False, LLDB won’t stop at the breakpoint

llvm-svn: 182059

function call exception catching breakpoints.  We need to force ourselves to stop in
that case.

<rdar://problem/13903801>

llvm-svn: 182056

- resolves llvm.org/pr14806

Patch by Matthew Sorrels!

llvm-svn: 182030

regions that aren't actually allocated in the
process.  This cache is used by the expression
parser if the underlying process doesn't support
memory allocation, to avoid needless repeated
searches for unused address ranges.

Also fixed a silly bug in IRMemoryMap where it
would continue searching even after it found a
valid region.

<rdar://problem/13866629>

llvm-svn: 182028

Fixed a 2 second delay when sending the 'k' (kill) packet that happened due to a race condition.

llvm-svn: 182025

Make type summary add and breakpoint command add show an helpful prototype + argument reference when manually typing Python code for these elements

llvm-svn: 181968

llvm-svn: 181948

Fixed an xpass due to r181841 on Linux with gcc.  Note that the clang variant contains to xfail, and r181841 is a fix for the test.

llvm-svn: 181918

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

- s/skipOnLinux/skipIfLinux/ to match style of every other decorator
- linkify bugizilla/PR numbers in comments

No intended change in functionality.

llvm-svn: 181913

llvm-svn: 181911

- "platform process list" command works on Linux now
- "process attach -n" (attach to process by name also works on Linux now)

llvm-svn: 181905

- read process information from /proc
- resolves llvm.org/pr14541 :)

Patch by Mike Sartain!

llvm-svn: 181904

Revert r181833: lldb prompt issue still occurs on buildbot (http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/4124)
- maybe consider checking in the 'good' version of libedit to avoid ancient system version

llvm-svn: 181903

- filed llvm.org/pr16016
- fixed URL for llvm.org/pr16000

llvm-svn: 181902

- newlines from GetRepositoryPath output were interfering with ninja builds
- replace newlines with spaces
- remove *only* trailing spaces from repo path

llvm-svn: 181899

llvm-svn: 181885

llvm-svn: 181876

Python breakpoint actions can return False to say that they don't want to stop at the breakpoint to which they are associated
Almost all of the work to support this notion of a breakpoint callback was in place, but two small moving parts were missing:
a) the SWIG wrapper was not checking the return value of the script
b) when passing a Python function by name, the call statement was dropping the return value of the function
This checkin addresses both concerns and makes this work
Care has been taken that you only keep running when an actual value of False has been returned, and that any other value (None included) means Stop!

llvm-svn: 181866

process StopLocker (if there is a process) before it will hand out SBValues.  We were doing this in 
an ad hoc fashion previously, and then playing whack-a-mole whenever we found a place where we should
have been doing this but weren't.  Really, it doesn't make sense to be poking at SBValues when the target
is running, the dynamic and synthetic values can't really be computed, and the underlying memory may be
incoherent.

<rdar://problem/13819378> Sometimes when stepping fast, my inferior is killed by debugserver

llvm-svn: 181863

Don’t pop the process input reader for a “stop” event if ShouldBroadcastEvent has restarted the process.

llvm-svn: 181859

llvm-svn: 181858

llvm-svn: 181857

The command "po" by itself yields odd errors. I fixed the alias.

llvm-svn: 181856

Changes to the libc++ std::string data formatter

llvm-svn: 181855

A first pass at auto completion for variables and their children. This is currently hooked up for "frame variable" only. With a little work we can also enable it for the "expression" command and also for other things.

llvm-svn: 181850

llvm-svn: 181845

Combine N_GSYM stab entries with their non-stab counterpart (data symbols) to make the symbol table smaller with less duplicate named symbols.

llvm-svn: 181841

Fixed the test case to pass on Darwin. This might pass on linux as well. The test case now properly validates g_points as a global for the class A version, and the static variable for the file static.

llvm-svn: 181840

- unable to repro locally, much like many people commenting on the issue

llvm-svn: 181833

- fix typo initializing unique_ptr
- add missing throw specifier to play nice with older libstdc++ exception class

llvm-svn: 181831

- older versions of clang are unable to include <chrono> from libstdc++
- skipping tests until buildbots are updated

llvm-svn: 181829

- test_breakpoint_callback -- filed llvm.org/pr-16000
- test_listener_resume -- resume a process from a thread waiting on SBListener
- test_listener_event_description -- SBEvent description from SBListener thread
- test_listener_event_process -- query process/thread/stack info from SBListener thread

llvm-svn: 181819

llvm-svn: 181818

The "lldb" driver was interfering with STDOUT and STDERR if the output was over 1024 charcters long. The output was grabbing 1024 characters at a time, before it output the characters, it was writing characters to the screen to clear the current line. This has been fixed.

I also fixed the command interpreter from mixing the "(lldb) " prompt in with program output by always manually checking for program output. This was done by having the command interpreter know when it is in the middle of executing a command by setting a bool. This was needed since sometimes when a command would run the target, like with a command like 'expression (int)printf("hello\n")', the process would push a new input reader, and then pop it when it was done. This popping of the input reader would cause the command interpreter to get sent a reactivated message (from the private process state thread) and cause it to ask for another command, even though we were still in the middle of the command ('expression (int)printf("hello\n")'). Now we set a bool to true, run the command and set the bool to false. If we get reactivated while we are in the middle of a command, we don't say we are ready for a new command. This coupled with emitting the STDOUT/STDERR first after each command, followed by the command results, followed by then saying we are ready for a new command, should help cleanup the command line output on all platforms.

llvm-svn: 181807