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

llvm-svn: 194729

llvm-svn: 193831

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

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

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

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

llvm-svn: 192255

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

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

I now see no unexpected failures on FreeBSD on a local run of the test
suite.

llvm.org/pr17214
llvm.org/pr17225
llvm.org/pr17231
llvm.org/pr17232
llvm.org/pr17233

llvm-svn: 190709

llvm.org/pr15261 missing size for static arrays
llvm.org/pr15278 expressions generating signals
llvm.org/pr15824 thread states aren't properly maintained
llvm.org/pr16696 threaded inferior debugging not yet on FreeBSD
llvm.org/pr17214 inline stepping fails on FreeBSD
llvm.org/pr17225 Clang assertion failure
llvm.org/pr17226 frame info lost after failed expression evaluation
llvm.org/pr17228 test timeout

The first three are existing Linux issues that also affect FreeBSD.

llvm-svn: 190698

llvm-svn: 190695

http://llvm.org/pr17183 expression w/ varargs printf() fails
http://llvm.org/pr15302 'anonymous namespace' prefix missing

llvm-svn: 190415

llvm-svn: 190286

llvm-svn: 190285

http://www.llvm.org/pr16697

llvm-svn: 189668

    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

llvm-svn: 187814

llvm-svn: 187730

llvm-svn: 187660

mapping of source to assembly so that the same test script can be used
with more compilers.

Patch by Andy Kaylor!

Also marks the LLDB test of template parameters as xfail on icc.

llvm-svn: 187600

Thanks Stefanus!

llvm-svn: 187585

Also, rework the signed types test to check for signed or char type in the output as char is signed by default.

llvm-svn: 187533

Patch from Andy Kaylor.

llvm-svn: 187520

TODO: Improve coverage of SBTypeMember and of 'target module dump'.
llvm-svn: 187519

llvm-svn: 187507

Also update comment in const variables test to reflect ICC status.

llvm-svn: 187501

provide more detail on compiler compatibility, and to illustrate that this is
an issue with expression evaluation.

- Note that clang doesn't emit DW_TAG_const_type, which might be okay if there's
no such thing as a non-const rvalue reference.  How about foo(make_int())?

llvm-svn: 187499

- disable some TestConcurrentEvents cases (which are affected by llvm.org/pr16714 -- watchpoints in multithreaded programs)
- relax number-of-bp-locations check in TestUniqueTypes/TestUnsignedTypes
- skip TestDataFormatterStdVector cases with GCC 4.8 (known failure due to llvm.org/pr15301)
- workaround for race condition in TestHelloWorld.py
- update TestSettings.py to work on distros (like Fedora) that have /bin/cat hardlinked to /usr/bin/cat

After these changes, the test suite should run cleanly against GCC 4.8 (with DWARF v4)!

llvm-svn: 187451

llvm-svn: 187415

PR title updated to indicate that FreeBSD is also affected: Backtrace
command does not display c++ member function names on Linux or FreeBSD

llvm-svn: 187127

These fail due to:
error: Expression can't be run, because there is no JIT compiled function

llvm-svn: 187072

llvm-svn: 186992

delete a constant after we replaced it with a
dynamically-computed value.  Also ensured that we
replace all users of the constant if there are
multiple ones.  Added a testcase.

<rdar://problem/14379043>

llvm-svn: 186363