Variable handling will be sunk into DwarfFile so that abstract variables
and the like can be shared across multiple CUs (to handle cross-CU
inlining, for example).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220453 91177308-0d34-0410-b5e6-96231b3b80d8
Use the DwarfDebug in one function that previously took it as a
parameter, and lay the foundation for use this for other operations
coming soon.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@220452 91177308-0d34-0410-b5e6-96231b3b80d8
And since it /looked/ like the DwarfStrSectionSym was unused, I tried
removing it - but then it turned out that DwarfStringPool was
reconstructing the same label (and expecting it to have already been
emitted) and uses that.
So I kept it around, but wanted to pass it in to users - since it seemed
a bit silly for DwarfStringPool to have it passed in and returned but
itself have no use for it. The only two users don't handle strings in
both .dwo and .o files so they only ever need the one symbol - no need
to keep it (and have an unused symbol) in the DwarfStringPool used for
fission/.dwo.
Refactor a bunch of accelerator table usage to remove duplication so I
didn't have to touch 4-5 callers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217628 91177308-0d34-0410-b5e6-96231b3b80d8
Pulls out some more code from some of the rather monolithic DWARF
classes. Unlike the address table, the string table won't move up into
DwarfDebug - each DWARF file has its own string table (but there can be
only one address table).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207277 91177308-0d34-0410-b5e6-96231b3b80d8
Some of these types (DwarfDebug in particular) are quite large to begin
with (and I keep forgetting whether DwarfFile is in DwarfDebug or
DwarfUnit... ) so having a few smaller files seems like goodness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207010 91177308-0d34-0410-b5e6-96231b3b80d8
