I know what would be cool! We should align the compact unwind section because
aligned data access is faster.
<rdar://problem/13723271>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180171 91177308-0d34-0410-b5e6-96231b3b80d8
Compact unwind has an encoding for when we're not able to generate compact
unwind and must generate an EH frame instead. Track that, but still emit that CU
encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179220 91177308-0d34-0410-b5e6-96231b3b80d8
We now emit a line table for each compile unit. To reduce the prologue size
of each line table, the files and directories used by each compile unit are
stored in std::map<unsigned, std::vector< > > instead of std::vector< >.
The prologue for a lto'ed image can be as big as 93K. Duplicating 93K for each
compile unit causes a huge increase of debug info. With this patch, each
prologue will only emit the files required by the compile unit.
rdar://problem/13342023
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176605 91177308-0d34-0410-b5e6-96231b3b80d8
We generate one line table for each compilation unit in the object file.
Reviewed by Eric and Kevin.
rdar://problem/13067005
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174445 91177308-0d34-0410-b5e6-96231b3b80d8
Add the x32 environment kind to the triple, and separate the concept of
pointer size and callee save stack slot size, since they're not equal
on x32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173175 91177308-0d34-0410-b5e6-96231b3b80d8
AT_producer. Which includes clang's version information so we can tell
which version of the compiler was used.
This is the first of two steps to allow us to do that. This is the llvm-mc
change to provide a method to set the AT_producer string. The second step,
coming soon to a clang near you, will have the clang driver pass the value
of getClangFullVersion() via an flag when invoking the integrated assembler
on assembly source files.
rdar://12955296
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172630 91177308-0d34-0410-b5e6-96231b3b80d8
compilation directory.
This defaults to the current working directory, just as it always has,
but now an assembler can choose to override it with a custom directory.
I've taught llvm-mc about this option and added a test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170371 91177308-0d34-0410-b5e6-96231b3b80d8
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169131 91177308-0d34-0410-b5e6-96231b3b80d8
to support it. Original patch with the parsing and plumbing by the PaX team and
Roman Divacky. I added the bits in MCDwarf.cpp and the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168565 91177308-0d34-0410-b5e6-96231b3b80d8
This untangles the switch cases of the old Move and RelMove opcodes a bit
and makes it clear how to add new instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168534 91177308-0d34-0410-b5e6-96231b3b80d8
Give MCCFIInstruction a single, private constructor and add helper static
methods that create each type of cfi instruction. This is is preparation
for changing its representation. The representation with a pair
MachineLocations older than MC and has been abused quiet a bit to support
more cfi instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168532 91177308-0d34-0410-b5e6-96231b3b80d8
debug info for assembly files. We were already doing the right thing when
producing debug info for C/C++.
ELF linkers don't know dwarf, so they depend on these relocations to produce
valid dwarf output.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151655 91177308-0d34-0410-b5e6-96231b3b80d8
functional change in r147860 to use DW_TAG_label's instead TAG_subprogram's.
This only changes names and updates comments. No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147877 91177308-0d34-0410-b5e6-96231b3b80d8
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
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
