llvm-svn: 183454

Breaks linux build bots (I thought the problem was something else).

llvm-svn: 183447

Seems we emit the parameter ordering number (spuriously named 'arg
number') in the debug info, so there's no need to search through the
variable list to figure out the parameter ordering. This implementation
does 'always' do the work, even in non-optimized debug info (the
previous implementation checked the existence of the 'variables' list on
the subprogram which is only present in optimized builds).

No intended functionality change.

llvm-svn: 183446

Reapply 183270.

llvm-svn: 183445

binary that is used for the test.  Caught by Jim Grosbach!

rdar://11791371

llvm-svn: 183442

Reapply 183269.

llvm-svn: 183441

llvm-svn: 183439

Reapply 183268.

llvm-svn: 183438

Reapply 183267.

llvm-svn: 183436

Add more InstRW mappings.

Reapply 183266.

llvm-svn: 183435

llvm-svn: 183433

Reapply 183265.

llvm-svn: 183432

Reapply 183264.

llvm-svn: 183430

Reapply 183263.

llvm-svn: 183428

Reapply 183262.

llvm-svn: 183427

llvm-svn: 183426

Reapply 183261.

llvm-svn: 183425

from the LC_DATA_IN_CODE load command.  And when disassembling print
the data in code formatted for the kind of data it and not disassemble those
bytes.

I added the format specific functionality to the derived class MachOObjectFile
since these tables only appears in Mach-O object files. This is my first
attempt to modify the libObject stuff so if folks have better suggestions
how to fit this in or suggestions on the implementation please let me know.

rdar://11791371

llvm-svn: 183424

Reapply of 183260.

llvm-svn: 183423

This reverts commit 183328. It caused pr16244 and broke the bots.

llvm-svn: 183422

Reapply of 183259.

llvm-svn: 183421

Spotted by Benjamin Kramer.

llvm-svn: 183413

llvm-svn: 183403

llvm-svn: 183385

FIXME: Is it false alarm?
llvm-svn: 183371

llvm-svn: 183370

llvm-svn: 183369

llvm-svn: 183365

llvm-svn: 183363

llvm-svn: 183362

Caching it as a pointer allows us to reset it if the TargetMachine object
changes.

llvm-svn: 183361

llvm-svn: 183360

The TargetLoweringInfo object is owned by the TargetMachine. In the future, the
TargetMachine object may change, which may also change the TargetLoweringInfo
object.

llvm-svn: 183356

The previous name `Ref` is overly generic.

llvm-svn: 183354

A user shouldn't care about the internal state, and these methods by
their very nature require asserting a predicate on the internal state.
As such, they cannot be used safely without introducing hidden
long-distance dependencies on the manner of construction of the
BinaryRef.

Use writeAsBinary(raw_ostream &) and writeAsHex(raw_ostream &) if you
need to access the data in a binary or hex format.

llvm-svn: 183353

This hides the implementation. A future commit will remove the
error-prone getHex() and getBinary() methods.

llvm-svn: 183352

llvm-svn: 183351

And add a doxygen comment.

llvm-svn: 183350

This avoids making assumptions about the data representation.

llvm-svn: 183349

Also, state an invariant.

llvm-svn: 183348