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

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

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

llvm-svn: 193877

llvm-svn: 193843

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

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

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

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

llvm-svn: 191717

- test wasn't checking for a stop reason before issuing the 'script' command
- should resolve intermittent failure on the Linux GCC buildbot

llvm-svn: 191708

- stop hooks sometimes fail to fire on Linux

llvm-svn: 191704

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

Fix TestFrames.py error to check against a None pc value.

llvm-svn: 191470

Fix the thread jump test case for 32-bit inferiors. A jump was going back to a function call using a source line number. However, the parameters being passed to the function were setup before the instruction we jumped to. In other words, the source line was associated with assembly after the function parameters had been setup for the function to be called.

llvm-svn: 191457

- Removes the block in UnwindLLDB::AddOneMoreFrame that tests for a bad stack setup,
since it is neither correct (tests the FP GPR), complete (doesn't consider multi-frame
cycles), nor reachable (the construction of RegisterContextLLDB will fail in the case 
where either of the two (why just two?) previous frames have the same canonical frame
address as the frame that we propose adding to the stack).

llvm-svn: 191430

- to verify that r191392 has the desired effect

llvm-svn: 191396

llvm-svn: 191383

llvm-svn: 191321

to build out the symbol table as addresses are used, and implements
the mechanism for ELF to add stripped symbols from eh_frame.

Uses this mechanism to allow disassembly for addresses corresponding
to stripped symbols for ELF, and provide hooks to implement this for
PE COFF.

Also removes eSymbolContextTailCall in favor of an option for
ResolveSymbolContextForAddress for consistency with the documentation
for eSymbolContextEverything.  Essentially, this is just an option for
interpreting the so_addr.
                  

llvm-svn: 191307

Specifically, allows the unwinder to handle the case where sc.function
gets resolved with a pc that is one past the address range of the function
(consistent with a tail call).  However, there is no matching symbol.

Adds eSymbolContextTailCall to provide callers with control over the scope
of symbol resolution and to allow ResolveSymbolContextForAddress to handle
tail calls since this routine is common to unwind and disassembly.

llvm-svn: 191102

- last remaining failure on the clang buildbot

llvm-svn: 191047

- tests are now anostic to the currently selected thread, as that is a frontend (i.e. driver) decision
- this is in preparation to a fix to POSIXThread::BreakNotify that will be committed shortly

Reviewed by: Matt Kopec

llvm-svn: 191041

- prompt disappears with older libedit versions
- will re-enable once we have a recent libedit on the buildbot in question

llvm-svn: 190889

llvm-svn: 190884

- original bug llvm.org/pr14323 is long closed

llvm-svn: 190865

llvm-svn: 190815

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