llvm-svn: 163421

For some reason .lcomm uses byte alignment and .comm log2 alignment so we can't
use the same setting for both. Fix this by reintroducing the LCOMM enum.
I verified this against mingw's gcc.

llvm-svn: 163420

This is not an exhaustive set, but something we can build on.

Contributer: Vladimir Medic
llvm-svn: 163419

llvm-svn: 163418

Train LLDB to deal with bad linker N_SO entries that point to our source files for debug map + DWARF in .o file debugging.

llvm-svn: 163417

llvm-svn: 163416

llvm-svn: 163415

llvm-svn: 163414

llvm-svn: 163413

llvm-svn: 163412

llvm-svn: 163411

llvm-svn: 163410

When adding the next statement to the CoreEngine's work list, we take care
of all the special cases first. We certainly shouldn't be building
PostStmts with null statements (the diagnostics machinery assumes such
StmtPoints do not exist), and we should find out sooner if we're missing
a special case.

A refinement of r163402 that should help prevent further issues like PR13760.

llvm-svn: 163409

llvm-svn: 163408

Don't warn when the sizeof argument is an array with the same element
type as the pointee of the return type.

llvm-svn: 163407

llvm-svn: 163406

llvm-svn: 163405

llvm-svn: 163404

llvm-svn: 163403

GCC destroys temporary objects more aggressively than clang, so this
results in incorrect behavior when compiling GCC Release builds.

We could avoid this issue under C++11 by preventing getAs from being
called when 'this' is an rvalue:

  template<class ElemTy> const ElemTy *getAs() const & { ... }
  template<class ElemTy> const ElemTy *getAs() const && = delete;

Unfortunately, we do not have compatibility macros for this behavior yet.

This will hopefully fix PR13760 and PR13762.

llvm-svn: 163402

llvm-svn: 163401

llvm-svn: 163400

The attached patch fixes a problem with performing an attach from the SBTarget API on Linux (and other systems that use ProcessPOSIX).
 
When Process::Attach was called from SBTarget, it resulted in a call to a form of the DoAttachWithID function that wasn't implemented in ProcessPOSIX, and so it fell back to the default implementation (which just returns an error).  It didn't seem necessary to use the attach_info parameter for this case, so I just implemented it as a call to the simpler version of the function.
 
In debugging this problem, I also found that SBTarget wasn't checking the return value from the Attach call, causing it to hang when the attach fails.

llvm-svn: 163399

The attached patch adds support for debugging 32-bit processes when running a 64-bit lldb on an x86_64 Linux system.
 
Making this work required two basic changes:
 
1)      Getting lldb to report that it could debug 32-bit processes
2)      Changing an assumption about how ptrace works when debugging cross-platform
 
For the first change, I took a conservative approach and only enabled this for x86_64 Linux platforms.  It may be that the change I made in Host.cpp could be extended to other 64-bit Linux platforms, but I'm not familiar enough with the other platforms to know for sure.
 
For the second change, the Linux ProcessMonitor class was assuming that ptrace(PTRACE_[PEEK|POKE]DATA...) would read/write a "word" based on the child process word size.  However, the ptrace documentation says that the "word" size read or written is "determined by the OS variant."  I verified experimentally that when ptracing a 32-bit child from a 64-bit parent a 64-bit word is read or written.

llvm-svn: 163398

within part of a particular method.

llvm-svn: 163397

The 'select' transformations apply to all ARM architectures and don't
require hasV6T2Ops.

llvm-svn: 163396

- Darwin lied about not supporting .lcomm and turned it into zerofill in the
  asm parser. Push the zerofill-conversion down into macho-specific code.
- This makes the tri-state LCOMMType enum superfluous, there are no targets
  without .lcomm.
- Do proper error reporting when trying to use .lcomm with alignment on a target
  that doesn't support it.
- .comm and .lcomm alignment was parsed in bytes on COFF, should be power of 2.
- Fixes PR13755 (.lcomm crashes on ELF).

llvm-svn: 163395

llvm-svn: 163394

Remove the infinite recursion check for now, as we don't have __thread on Mac, and TSD is an overkill.

llvm-svn: 163393

 -- exit from infinite recursion in CHECK()
 -- print a verbose message if mapping of the shadow memory has failed.

llvm-svn: 163391

gas accepts this and it seems to be common enough to be worth supporting. This
doesn't affect the parsing of reg operands outside of .cfi directives.

llvm-svn: 163390

llvm-svn: 163389

llvm-svn: 163388

llvm-svn: 163387

This allows linking to LibASTMatchersRefernce.html#<matcher><N>Anchor to
link to the N'the declaration of a matcher and automatically expand
its documentation.

llvm-svn: 163386

class itself. This caused some confusion (intuitively, a class is not
derived from itself) and makes it hard to write certain matchers, e.g.
"match and bind any pair of base and subclass".

The original behavior can be achieved with a new isA-matcher.  Similar
to all other matchers, this matcher has the same behavior and name as
the corresponding AST-entity - in this case the isa<>() function.

llvm-svn: 163385

Our tests expect that a 16M block will fit in the quarantine.

llvm-svn: 163384

llvm-svn: 163383

Implements the hasAncestor matcher. This builds
on the previous patch that introduced DynTypedNode to build up
a parent map for an additional degree of freedom in the AST traversal.

The map is only built once we hit an hasAncestor matcher, in order
to not slow down matching for cases where this is not needed.

We could implement some speed-ups for special cases, like building up
the parent map as we go and only building up the full map if we break
out of the already visited part of the tree, but that is probably
not going to be worth it, and would make the code significantly more
complex.

Major TODOs are:
- implement hasParent
- implement type traversal
- implement memoization in hasAncestor

llvm-svn: 163382

[ASan] hack initialization-bug test so that it stably passes on both Linux and Mac: make the bug appear independent of the translation unit order

llvm-svn: 163381