llvm-svn: 192339

llvm-svn: 192338

Differential Revision: http://llvm-reviews.chandlerc.com/D1881

llvm-svn: 192337

Based on the POSIX x86_64 register context.  This is sufficient for opening
a mips64 (big endian) core file.  Subsequent changes will connect the
disassembler, dynamic loader support, ABI, etc.

Review: http://llvm-reviews.chandlerc.com/D1873

(Missed "svn add" on this file in r192335)

llvm-svn: 192336

Based on the POSIX x86_64 register context.  This is sufficient for opening
a mips64 (big endian) core file.  Subsequent changes will connect the
disassembler, dynamic loader support, ABI, etc.

Review: http://llvm-reviews.chandlerc.com/D1873
llvm-svn: 192335

Fix getIntegerTypeOrder() to properly handle enums by first unwrapping their underlying integer type.  This is a precondition for calling getIntegerRank().

Fixes an assertion failure in a test case involving vectors.

Fixes <rdar://problem/15091442>

Please somebody check this.

llvm-svn: 192334

made sure we don't keep around no-longer-valid
ASTTransformers.

<rdar://problem/15182379>

llvm-svn: 192333

llvm-svn: 192332

This exposes a 32-bit view of the registry even when Clang is built as a 64-bit
program. Since Visual Studio is a 32-bit application, this is necessary for us
to find it.

llvm-svn: 192331

ins/ext.

llvm-svn: 192330

This reverts commit r192316. The original change introduced circular
dependencies between libTarget and backends. That would broke a build unless
link everything into one big binary.

llvm-svn: 192329

Refine string literal concatenation warning within an NSArray literal to not warn when the literal comes from a macro expansion.  Fixes <rdar://problem/15147688>.

llvm-svn: 192328

importer to avoid duplicate imports of anonymous
structs.

<rdar://problem/14421722>

llvm-svn: 192327

LLDB (Terminal) User Interface
==============================
This directory contains the curses user interface for LLDB. To use it, ensure Python can find your lldb module. You may have to modify PYTHONPATH for that purpose:

$ export PYTHONPATH=/path/to/lldb/module

Then, run the lui.py. To load a core file:
$ ./lui.py --core core

To create a target from an executable:
$ ./lui.py /bin/echo "hello world"

To attach to a running process:
$ ./lui.py --attach <pid>


Known Issues
============
1. Resizing the terminal will most likely cause lui to crash.
2. Missing paging in command-window
3. Only minimal testing (on Ubuntu Linux x86_64)

Missing Features
================
- stdin/stdout/stderr windows
- memory window
- backtrace window
- threads window
- tab-completion
- syntax-highlighting (via pygments library)
- (local) variables window
- registers window
- disassembly window
- custom layout

llvm-svn: 192326

llvm-svn: 192325

ASTImporter when importing the following types:

typedef struct {
} A;

typedef struct {
  A a;
} B;

Suppose we have imported B, but we did not at that
time need to complete it.  Then later we want to
import A.  The struct is anonymous, so the first
thing we want to do is make sure no other anonymous
struct already matches it.  So we set up an
StructuralEquivalenceContext and compare B with A.

This happens at ASTImporter.cpp:2179.

Now, in this scenario, B is not complete.  So we go
and import its fields, including a, which causes A
to be imported.  The ASTImporter doesn’t yet have A
in its list of already-imported things, so we
import A.

After the StructuralEquivalenceContext is finished
determining that A and B are different, the
ASTImporter concludes that A must be imported
because no equivalent exists, so it imports a second
copy of A.  Now we have two different structs
representing A.  This is really bad news.

The patch allows the StructuralEquivalenceContext to
use the original version of B when making its
comparison, obviating the need for an import and
cutting this loop.

llvm-svn: 192324

ObjectFile::CopyData is used to copy a block of target memory to the
caller's buffer (e.g. for "memory read").  This should be a straight
memcpy, and not byte-swapped if the target and host have different
endianness.

Add a new DataExtractor::CopyData() method that performs this straight
copy and use it in ObjectFile::CopyData().

llvm-svn: 192323

llvm-svn: 192322

template_type and template_value are updated to use DIRef.

Paired commit with r192320.

llvm-svn: 192321

template_value are updated to use DIRef.

A paired commit at clang is required due to changes to DIBuilder.

llvm-svn: 192320

llvm-svn: 192319

llvm-svn: 192318

and use it to infer all properties as 'atomic'.
// rdar://14988132

llvm-svn: 192317

Making them proper functions defined in the (shared)lib instead of
static inlines defined in the header files makes it possible to
actually distribute a binary compiled against the shared library
without having to worry about getting undefined symbol errors when
calling e.g LLVMInitializeAllTargetInfos because the shared library on
the other system was compiled with different targets.

Differential Revision: http://llvm-reviews.chandlerc.com/D1714

llvm-svn: 192316

llvm-svn: 192315

marked all variables as "unknown" at the start of a loop.  The new version
keeps the initial state of variables unchanged, but issues a warning if the
state at the end of the loop is different from the state at the beginning.
This patch will eventually be replaced with a more precise analysis.

Initial patch by chris.wailes@gmail.com.  Reviewed and edited by
delesley@google.com.

llvm-svn: 192314

llvm-svn: 192313

Reviewed at http://llvm-reviews.chandlerc.com/D1867

llvm-svn: 192312

A file with .objtxt extension is parsed in readFile(), but because we did not
propagate that information to the calling side, calling side would try to parse
it again. This patch will fix the issue by adding an extra parameter to
readFile().

llvm-svn: 192311

llvm-svn: 192310

to use DIScopeRef.

llvm-svn: 192309

Follow-up from r192240.

This makes it an error to use callee-cleanup conventions on variadic
functions, except for __fastcall and __stdcall, which we ignore with
a warning for GCC and MSVC compatibility.

Differential Revision: http://llvm-reviews.chandlerc.com/D1870

llvm-svn: 192308

llvm-svn: 192307

Remove 32-bit POSIX register hack in ConvertBetweenRegisterKinds.

llvm-svn: 192306

suppression of strong lifetime qualifiers when
inferring property. // rdar://15082812

llvm-svn: 192305

llvm-svn: 192304

MCStreamer now owns the target streamer. This prevents leaking the target
streamer.

llvm-svn: 192303

  If a function seen at compile time is not necessarily the one linked to
the binary being built, it is illegal to change the actual arguments
passing to it. 

  e.g. 
   --------------------------
   void foo(int lol) {
     // foo() has linkage satisifying isWeakForLinker()
     // "lol" is not used at all.
   }

   void bar(int lo2) {
      // xform to foo(undef) is illegal, as compiler dose not know which
      // instance of foo() will be linked to the the binary being built.
      foo(lol2); 
   }
  -----------------------------

  Such functions can be captured by isWeakForLinker(). NOTE that
mayBeOverridden() is insufficient for this purpose as it dosen't include
linkage types like AvailableExternallyLinkage and LinkOnceODRLinkage.
Take link_odr* as an example, it indicates a set of *EQUIVALENT* globals
that can be merged at link-time. However, the semantic of 
*EQUIVALENT*-functions includes parameters. Changing parameters breaks
the assumption.

  Thank John McCall for help, especially for the explanation of subtle
difference between linkage types.

  rdar://11546243

llvm-svn: 192302

Allow Process::WaitForProcessToStop to return immediately if process is already in the stopped state
- By default, the above function will wait for at least one event
- Set wait_always=false to make the function return immediately if the process is already stopped

llvm-svn: 192301

With this patch we produce alias for cases like

template<typename T>
struct foobar {
  foobar() {
  }
};
template struct foobar<void>;

It is safe to use aliases to weak symbols, as long and the alias itself is also
weak.

llvm-svn: 192300