After solving the issue in llvm.org/pr17226 these two tests still fail,
now for other reasons.

llvm-svn: 194729

After solving llvm.org/pr17226 these two tests now fail for the same reason
they do on Linux.

llvm-svn: 194726

It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009. 

It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience.  Using the EvaluateExpressionOptions removes the need for them.

Using that it gets the --debug option from Greg's patch to work cleanly.

It also adds another EvaluateExpressionOption to not trap exceptions when running expressions.  You shouldn't
use this option unless you KNOW your expression can't throw beyond itself.  This is:

<rdar://problem/15374885>

At present this is only available through the SB API's or python.

It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.

llvm-svn: 194182

Fixed the test case for "test/functionalities/exec/TestExec.py" on Darwin.

The issue was breakpoints were persisting and causing problems. When we exec, we need to clear out the process and target and start fresh with nothing and let the breakpoints populate themselves again. This patch correctly clears out the breakpoints and also flushes the process so that the objects (process/thread/frame) give out valid information.

llvm-svn: 194106

For this test case, one needs to get the name of the symbol since we don't have debug info to generate an SBFunction

llvm-svn: 193879

Use 0x00... as the magic constant to write in st0. That should be reliably 0 regardless of OS/hardware

llvm-svn: 193877

llvm-svn: 193844

llvm-svn: 193843

llvm-svn: 193831

Given that, this test will never pass
Marking as expected failure pending a fix

llvm-svn: 193830

llvm-svn: 193829

Mark it as expected to fail pending a fix

llvm-svn: 193828

llvm-svn: 193827

llvm-svn: 193826

llvm-svn: 193825

llvm-svn: 193824

llvm-svn: 193822

Workaround the DWARF info is anticipating the derived class assignment issue in this test case for now

llvm-svn: 193821

llvm-svn: 193809

llvm-svn: 193793

(Threaded inferior debugging not yet available on FreeBSD.)

llvm-svn: 193771

llvm-svn: 193715

One of the things that dynamic typing affects is the count of children a type has
Clear out the flag that makes us blindly believe the children count when a dynamic type change is detected

llvm-svn: 193663

Fixing an issue in yesterday's dynamic type changes where we would not craft a valid SBType given debug information
Added a test case to help us detect regression in this realm

llvm-svn: 193631

llvm-svn: 193628

This commit reimplements the TypeImpl class (the class that backs SBType) in terms of a static,dynamic type pair

This is useful for those cases when the dynamic type of an ObjC variable can only be obtained in terms of an "hollow" type with no ivars
In that case, we could either go with the static type (+iVar information) or with the dynamic type (+inheritance chain)

With the new TypeImpl implementation, we try to combine these two sources of information in order to extract as much information as possible
This should improve the functionality of tools that are using the SBType API to do extensive dynamic type inspection

llvm-svn: 193564

and unions the same way that C would.

<rdar://problem/11987906>

llvm-svn: 193016

This is the last piece of work for "formats in categories": we now cache formats as well as summaries and synthetics

llvm-svn: 192928

To make this work this patch extends LLDB to:

- Explicitly track the link_map address for each module. This is effectively the module handle, not sure why it wasn't already being stored off anywhere. As an extension later, it would be nice if someone were to add support for printing this as part of the modules list.

- Allow reading the per-thread data pointer via ptrace. I have added support for Linux here. I'll be happy to add support for FreeBSD once this is reviewed. OS X does not appear to have __thread variables, so maybe we don't need it there. Windows support should eventually be workable along the same lines.

- Make DWARF expressions track which module they originated from.

- Add support for the DW_OP_GNU_push_tls_address DWARF opcode, as generated by gcc and recent versions of clang. Earlier versions of clang (such as 3.2, which is default on Ubuntu right now) do not generate TLS debug info correctly so can not be supported here.

- Understand the format of the pthread DTV block. This is where it gets tricky. We have three basic options here:

  1) Call "dlinfo" or "__tls_get_addr" on the inferior and ask it directly. However this won't work on core dumps, and generally speaking it's not a good idea for the debugger to call functions itself, as it has the potential to not work depending on the state of the target.

  2) Use libthread_db. This is what GDB does. However this option requires having a version of libthread_db on the host cross-compiled for each potential target. This places a large burden on the user, and would make it very hard to cross-debug from Windows to Linux, for example. Trying to build a library intended exclusively for one OS on a different one is not pleasant. GDB sidesteps the problem and asks the user to figure it out.

  3) Parse the DTV structure ourselves. On initial inspection this seems to be a bad option, as the DTV structure (the format used by the runtime to manage TLS data) is not in fact a kernel data structure, it is implemented entirely in useerland in libc. Therefore the layout of it's fields are version and OS dependent, and are not standardized.

  However, it turns out not to be such a problem. All OSes use basically the same algorithm (a per-module lookup table) as detailed in Ulrich Drepper's TLS ELF ABI document, so we can easily write code to decode it ourselves. The only question therefore is the exact field layouts required. Happily, the implementors of libpthread expose the structure of the DTV via metadata exported as symbols from the .so itself, designed exactly for this kind of thing. So this patch simply reads that metadata in, and re-implements libthread_db's algorithm itself. We thereby get cross-platform TLS lookup without either requiring third-party libraries, while still being independent of the version of libpthread being used.

Test case included.

llvm-svn: 192922

Some linkers (GNU ld) are picky about library order, so if we import libraries as part of our LDFLAGS then that needs to come after any DYLIB_NAME which might require that library.

llvm-svn: 192917

Extend DummySyntheticProvider to actually use debug-info vended children as the source of information
Make Python synthetic children either be valid, or fallback to the dummy, like their C++ counterparts

This allows LLDB to actually stop bailing out upon encountering an invalid synthetic children provider front-end, and still displaying the non synthetized ivar info

llvm-svn: 192741

llvm-svn: 192467

Remove 32-bit POSIX register hack in ConvertBetweenRegisterKinds.

llvm-svn: 192306

Use 32-bit register enums without gaps on 64-bit hosts.
Don't show 64-bit registers when debugging 32-bit targets.
Add psuedo gpr registers (ax, ah, al, etc.)
Add mmx registers.
Fix TestRegisters.py to not read ymm15 register on 32-bit targets.
Fill out and move gcc/dwarf/gdb register enums to RegisterContext_x86.h

llvm-svn: 192263

Making GetNumberOfDirectBaseClasses() work for ObjC pointers, and for classes for which we don't have full debug info

llvm-svn: 192255

llvm-svn: 192134

llvm-svn: 192132

This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases

More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff:
this ValueObject does not have a summary
its children have no synthetic children
its children are not a non-empty base class without a summary
its children do not have a summary that asks for children to show up
the aggregate length of all the names of all the children is <= 50 characters
you did not ask to see the types during a printout
your pointer depth is 0

This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?)

Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be)

llvm-svn: 191996

This fixes TestBreakpointCommand.

llvm-svn: 191868

llvm-svn: 191717