Fix DW_AT_data_member_location for bit-fields. It points to the location of annonymous field that covers respective field.

llvm-svn: 86054

llvm-svn: 86043

llvm-svn: 85909

warning from gcc by removing VISIBILITY_HIDDEN attributes.  

llvm-svn: 85873

Do not held on to DenseMap slot accross map insertion. The insertion may cause the map to grow rending the slot invalid.
Use this opportunity to use ValueMap instead of DenseMap.

llvm-svn: 85298

llvm-svn: 84276

If there is not any llvm instruction associated with each lexical scope encoded in debug info then create such scope on demand for variable info.

llvm-svn: 84262

llvm-svn: 84134

s/DebugLoc.InlinedLoc/DebugLoc.InlinedAtLoc/g

llvm-svn: 84054

llvm-svn: 83950

llvm-svn: 83922

Extract scope information from the variable itself, instead of relying on alloca or llvm.dbg.declare location.

While recording beginning of a function, use scope info from the first location entry instead of just relying on first location entry itself.

llvm-svn: 83684

Check invalid debug info for enums. This may happen when underlyng enum is optimized away. Eventually DwarfChecker will clean this up during llvm verification stage.

llvm-svn: 83655

Do not record line number to implicitly mark start of function if function has arguments. Extra line number entries trip gdb in some cases.

llvm-svn: 83563

This is not yet enabled.

llvm-svn: 83400

llvm-svn: 83367

llvm-svn: 83362

This will be used by processDebugLoc().

llvm-svn: 83361

llvm-svn: 83355

Existence of a compile unit for input source file is a good indicator to check debug info's presence in a module.

llvm-svn: 83348

This can happen if debug info is processed lazily.

llvm-svn: 83347

void foo() { static int bar = 42; }
Here, foo's DIE is parent of bar's DIE.

llvm-svn: 83344

llvm-svn: 83343

llvm-svn: 83317

Add support to extract lexical scope information from DebugLoc attached with an machine instruction. 
This is not yet enabled.

llvm-svn: 83210

llvm-svn: 83207

llvm-svn: 83182

information.  This allows arbitrary code involving DW_OP_plus_uconst
and DW_OP_deref.  The scheme allows for easy extention to include,
any, or all of the DW_OP_ opcodes.  I thought about just exposing all
of them, but, wasn't sure if people wanted the dwarf opcodes exposed
in the api.  Is that a layering violation?

With this scheme, the entire existing block scheme used by llvm-gcc
can be switched over to the new scheme.  I think that would be
cleaner, as then the compiler specific bits are not present in llvm
proper.  Before the old code can be yanked however, similar code in
clang would have to be removed.

Next up, more testing.

llvm-svn: 83120

llvm-svn: 83083

delete a few blank lines.

llvm-svn: 82729

llvm-svn: 82727

llvm-svn: 82591

llvm-svn: 82333

llvm-svn: 82332

it into all of its call sites and simplifying them.

llvm-svn: 81962

llvm-svn: 81542

the MCInst path of the asmprinter.  Instead, pull comment printing
out of the autogenerated asmprinter into each target that uses the
autogenerated asmprinter.  This causes code duplication into each
target, but in a way that will be easier to clean up later when more
asmprinter stuff is commonized into the base AsmPrinter class.

This also fixes an xcore strangeness where it inserted two tabs
before every instruction.

llvm-svn: 81396

llvm-svn: 81055

llvm-svn: 80637

llvm-svn: 80633