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

Patch by Rick Foos.

llvm-svn: 163380

[ASan] add Linux-specific test for initialization order that checks that we find a bug independently of translation units order

llvm-svn: 163379

llvm-svn: 163378

Apparently the output of this test is not deterministic.  Needs investigation.

llvm-svn: 163377

[Sanitizer] add --demangle option to llvm-symbolizer (for now just assume that __cxa_demangle option is available)

llvm-svn: 163376

While the check itself should count 0-based for the parameter index,
the diagnostic should be 1-based (first, second, third, not start at 0).

Fixes <rdar://problem/12249569>.

llvm-svn: 163375

(as this previously was the case before this was refactored).  We also shouldn't
need to specially handle BinaryOperators since the eagerly-assume heuristic tags
such nodes.

llvm-svn: 163374

of the analyzer, as the RetainReleaseChecker has many fine-grain
path diagnostic events that were not being checked.  This uncovered
an inconsistency between the path diagnostics between Objective-C
and Objective-C++ code in ConditionBRVisitor that was fixed in a recent
patch.

llvm-svn: 163373

implicit pointer-to-boolean conversions in condition expressions.  This would
result in inconsistent diagnostic emission between C and C++.

A consequence of this is now ConditionBRVisitor and TrackConstraintBRVisitor may
emit redundant diagnostics, for example:

  "Assuming pointer value is null" (TrackConstraintBRVisitor)
  "Assuming 'p' is null" (ConditionBRVisitor)

We need to reconcile the two, and perhaps prefer one over the other in some
cases.

llvm-svn: 163372

Add -exact-match option to FileCheck to allow clients to do exact matches without using regular expressions.

llvm-svn: 163371

- this should fix PR13780

llvm-svn: 163370

unexpanded parameter pack is a pack expansion. Thus, as with a non-type template
parameter which is a pack expansion, it needs to be expanded early into a fixed
list of template parameters.

Since the expanded list of template parameters is not itself a parameter pack,
it is permitted to appear before the end of the template parameter list, so also
remove that restriction (for both template template parameter pack expansions and
non-type template parameter pack expansions).

llvm-svn: 163369

The assembler can alias one instruction into another based
on the operands. For example the jump instruction "J" takes
and immediate operand, but if the operand is a register the
assembler will change it into a jump register "JR" instruction.

These changes are in the instruction td file.

Test cases included

Contributer: Vladimir Medic
llvm-svn: 163368

With some particularly evil casts, we can get an object whose dynamic type
is not actually a subclass of its static type. In this case, we won't even
find the statically-resolved method as a devirtualization candidate.

Rather than assert that this situation cannot occur, we now simply check
that the dynamic type is not an ancestor or descendent of the static type,
and leave it at that.

This error actually occurred analyzing LLVM: CallEventManager uses a
BumpPtrAllocator to allocate a concrete subclass of CallEvent
(FunctionCall), but then casts it to the actual subclass requested
(such as ObjCMethodCall) to perform the constructor.

Yet another crash in PR13763.

llvm-svn: 163367

llvm-svn: 163366

llvm-svn: 163365

Actually these are just stubs for parsing the directives.
Semantic support will come later.

Test cases included

Contributer: Vladimir Medic
llvm-svn: 163364

Test cases included

Contributer: Vladimir Medic
llvm-svn: 163363

return a CF object at all.

Fixes <rdar://problem/9566345>

llvm-svn: 163362

A bizarre series of coincidences led us to generate a previously-seen
node in the middle of processing an Objective-C message, where we assume
the receiver is non-nil. We were assuming that such an assumption would
never "cache out" like this, and blithely went on using a null ExplodedNode
as the predecessor for the next step in evaluation.

Although the test case committed here is complicated, this could in theory
happen in other ways as well, so the correct fix is just to test if the
non-nil assumption results in an ExplodedNode we've seen before.

<rdar://problem/12243648>

llvm-svn: 163361

- This patch is inspired by the failure of the following code snippet
  which is used to convert enumerable values into encoding bits to
  improve the readability of td files.

  class S<int s> {
    bits<2> V = !if(!eq(s, 8),  {0, 0},
                !if(!eq(s, 16), {0, 1},
                !if(!eq(s, 32), {1, 0},
                !if(!eq(s, 64), {1, 1}, {?, ?}))));
  }

  Later, PR8330 is found to report not exactly the same bug relevant
  issue to bit/bits values.

- Instead of resolving bit/bits values separately through
  resolveBitReference(), this patch adds getBit() for all Inits and
  resolves bit value by resolving plus getting the specified bit. This
  unifies the resolving of bit with other values and removes redundant
  logic for resolving bit only. In addition,
  BitsInit::resolveReferences() is optimized to take advantage of this
  origanization by resolving VarBitInit's variable reference first and
  then getting bits from it.

- The type interference in '!if' operator is revised to support possible
  combinations of int and bits/bit in MHS and RHS.

- As there may be illegal assignments from integer value to bit, says
  assign 2 to a bit, but we only check this during instantiation in some
  cases, e.g.

  bit V = !if(!eq(x, 17), 0, 2);

  Verbose diagnostic message is generated when invalid value is
  resolveed to help locating the error.

- PR8330 is fixed as well.

llvm-svn: 163360