aboutsummaryrefslogtreecommitdiffstats
path: root/include/llvm/Bitcode
diff options
context:
space:
mode:
authorKevin Enderby <enderby@apple.com>2012-01-10 17:52:29 +0000
committerKevin Enderby <enderby@apple.com>2012-01-10 17:52:29 +0000
commit38fdb7d9fc40e9f29c3156b6625cac8d91d562e1 (patch)
tree57d0e053f65e0c6840e28e007af6bb1c33f9fe12 /include/llvm/Bitcode
parent4ba0e75e4b1c557a9de5a3675357c2a4bf699a6a (diff)
downloadexternal_llvm-38fdb7d9fc40e9f29c3156b6625cac8d91d562e1.zip
external_llvm-38fdb7d9fc40e9f29c3156b6625cac8d91d562e1.tar.gz
external_llvm-38fdb7d9fc40e9f29c3156b6625cac8d91d562e1.tar.bz2
Various crash reporting tools have a problem with the dwarf generated for
assembly source when it generates the TAG_subprogram dwarf debug info for the labels that have nothing between them as in this bit of assembly source: % cat ZeroLength.s _func1: _func2: nop One solution would be to not emit the subsequent labels with the same address and use the next label with a different address or the end of the section for the AT_high_pc value of the TAG_subprogram. Turns out in llvm-mc it is not possible in all cases to determine of two symbols have the same value at the point we put out the TAG_subprogram dwarf debug info. So we will have llvm-mc instead of putting out TAG_subprogram's put out DW_TAG_label's. And the DW_TAG_label does not have a AT_high_pc value which avoids the problem. This commit is only the functional change to make the diffs clear as to what is really being changed. The next commit will be to clean up the names of such things like MCGenDwarfSubprogramEntry to something like MCGenDwarfLabelEntry. rdar://10666925 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147860 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'include/llvm/Bitcode')
0 files changed, 0 insertions, 0 deletions