History log of /external/llvm/test/MC/MachO/gen-dwarf.s
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
36b56886974eae4f9c5ebc96befd3e7bfe5de338 24-Apr-2014 Stephen Hines <srhines@google.com> Update to LLVM 3.5a.

Change-Id: Ifadecab779f128e62e430c2b4f6ddd84953ed617
/external/llvm/test/MC/MachO/gen-dwarf.s
767295f1143db4ed844ea9d25f9758e624c35302 25-Jan-2013 Eli Bendersky <eliben@google.com> Now that llvm-dwarfdump supports flags to specify which DWARF section to dump,
use them in tests that run llvm-dwarfdump. This is in order to make tests as
specific as possible.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173498 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/test/MC/MachO/gen-dwarf.s
eb6363adf05b65b0ec079ad7cbcb871acdb60a8c 27-Nov-2012 Eric Christopher <echristo@gmail.com> The section is .debug_line.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168666 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/test/MC/MachO/gen-dwarf.s
38fdb7d9fc40e9f29c3156b6625cac8d91d562e1 10-Jan-2012 Kevin Enderby <enderby@apple.com> 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
/external/llvm/test/MC/MachO/gen-dwarf.s
5a3d4c983069f0646065b773a7c11a900f9ff94a 13-Dec-2011 Nick Lewycky <nicholas@mxc.ca> Don't rely on a particular version string for llvm.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146456 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/test/MC/MachO/gen-dwarf.s
59164b731b36a1018a8ac241b0f2dc0a08dfec90 10-Dec-2011 Chandler Carruth <chandlerc@gmail.com> Don't assume things about the exact details of the LLVM version number,
such as what VCS information is attached.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146333 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/test/MC/MachO/gen-dwarf.s
94c2e85bea1ab1b837a4c055ccc83d5cd32dd027 09-Dec-2011 Kevin Enderby <enderby@apple.com> The second part of support for generating dwarf for assembly source files. This
generates the dwarf Compile Unit DIE and a dwarf subprogram DIE for each
non-temporary label.

The next part will be to get the clang driver to enable this when assembling
a .s file. rdar://9275556


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146262 91177308-0d34-0410-b5e6-96231b3b80d8
/external/llvm/test/MC/MachO/gen-dwarf.s