Based on D2050 by Timur Iskhodzhanov.

llvm-svn: 193619

DWARF parser: Use ArrayRef to represent form sizes and simplify DWARFDIE::extractFast() interface. No functionality change.

llvm-svn: 193560

Summary:
Use DWARF4 table of form classes to fetch attributes from DIE
in a more consistent way. This shouldn't change the functionality and
serves as a refactoring for upcoming change: DW_AT_high_pc has different
semantics depending on its form class.

Reviewers: dblaikie, echristo

Reviewed By: echristo

CC: echristo, llvm-commits

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

llvm-svn: 193553

llvm-svn: 193550

llvm-svn: 193432

llvm-svn: 193431

llvm-svn: 193429

llvm-svn: 193427

llvm-svn: 193363

llvm-svn: 193361

llvm-svn: 193350

llvm-svn: 193344

Includes a test case/FIXME demonstrating a bug/limitation in pointer to
member hashing. To be honest I'm not sure why we don't just always use
summary hashing for referenced types... but perhaps I'm missing
something.

llvm-svn: 193175

DWARF Type Hashing: Include reference and rvalue reference type in the declarable summary hashing path

More support for 7.25 Part 5.

llvm-svn: 193129

There are several other tag types that need similar handling but to
ensure test coverage they'll be coming incrementally.

llvm-svn: 193126

llvm-svn: 193125

And add the 'Test' suffix so the test case name matches the file name.

llvm-svn: 193119

This uses a map, keeping the type DIE numbering separate from the DIEs
themselves - alternatively we could do things the way GCC does if we
want to add an integer to the DIE type to record the numbering there.

llvm-svn: 193105

llvm-svn: 192924

llvm-svn: 192856

This allows us to produce the same hash as GCC for at least some simple
examples.

llvm-svn: 192855

GTest assumes the left hand side of the assert is the expectation and
the right hand side is the test result. It's easier to read gtest
failures when these things are ordered correctly.

llvm-svn: 192854

llvm-svn: 192836

This patch fixes a small mistake in MCDataAtom::addData() where it doesn't ever
call remap():

-  if (Data.size() > Begin - End - 1)
+  if (Data.size() > End + 1 - Begin)
     remap(Begin, End + 1);

This is currently not visible because of another bug is the disassembler, so
the patch includes a unit test.

Patch by Stephen Checkoway.

llvm-svn: 192823

Before this patch we would assert when building llvm as multiple shared
libraries (cmake's BUILD_SHARED_LIBS). The problem was the line

if (T.AsmStreamerCtorFn == Target::createDefaultAsmStreamer)

which returns false because of -fvisibility-inlines-hidden. It is easy
to fix just this one case, but I decided to try to also make the
registration more strict. It looks like the old logic for ignoring
followup registration was just a temporary hack that outlived its
usefulness.

This patch converts the ifs to asserts, fixes the few cases that were
registering twice and makes sure all the asserts compare with null.

Thanks for Joerg for reporting the problem and reviewing the patch.

llvm-svn: 192803

Also minor using namespace move so it's not hard-up against the function
definition and outside the namespace as is usual.

llvm-svn: 192744

llvm-svn: 192042

This should fix the i386 Darwin build-bot.

llvm-svn: 191840

This threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.  
It's useful for the memory managers that are allocating a section to know what the name of the section is.  
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what 
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about 
what each allocation is for.  This allows clients that supply their own memory managers to do this.  
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM 
client.

This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM.  I'm assuming that 
it's safe to change the C++ API because that API is allowed to change.  I'm assuming that it's safe to change 
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory 
management C API).

llvm-svn: 191804

- New ProcessInfo class to encapsulate information about child processes.
- Generalized the Wait() to support non-blocking wait on child processes.
- ExecuteNoWait() now returns a ProcessInfo object with information about
  the launched child. Users will be able to use this object to
  perform non-blocking wait.
- ExecuteNoWait() now accepts an ExecutionFailed param that tells if execution
  failed or not.

These changes will allow users to implement basic process parallel
tools.

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

llvm-svn: 191763

llvm-svn: 191723

Currently it will insert an illegal bitcast.
Arguably, the address space argument should be
added for the creation case.

llvm-svn: 191702

Inspired by the object from the SLPVectorizer. This found a minor bug in the
debug loc restoration in the vectorizer where the location of a following
instruction was attached instead of the location from the original instruction.

llvm-svn: 191673

llvm-svn: 191638

range that includes a tab character will cause out-of-bounds access to the
fixit string.

llvm-svn: 191563

llvm-svn: 191558

--gtest_filter was filtering an invalid name for the test.

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

llvm-svn: 191100

llvm-svn: 190485

It was turning the buildbots red.

llvm-svn: 190480

llvm-svn: 190472