This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
Originally committed as r197073 and reverted in r197079.
Recommitted as r197197 to reproduce the failure and reverted as r197199
Turns out there was unstable ordering in the type unit dumping code.
Fixed by using MapVector in DWARFContext to store the debug_types
comdat sections.
Recommitted as r197210 with a fix to dumping and reverted as r197211
because I was a bit gun shy and thought I saw a failure that turned out
to be unrelated.
So here we go - once more with feeling! \o/
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197275 91177308-0d34-0410-b5e6-96231b3b80d8
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
Originally committed as r197073 and reverted in r197079.
Recommitted as r197197 to reproduce the failure and reverted as r197199
Turns out there was unstable ordering in the type unit dumping code.
Fixed by using MapVector in DWARFContext to store the debug_types
comdat sections.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197210 91177308-0d34-0410-b5e6-96231b3b80d8
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
Originally committed as r197073 and reverted in r197079.
This commit originally got jumbled up with another build-breaking commit
and I can't find the failures I thought this caused anymore.
Recommitting to hopefully get some clean buildbot results to work from.
I have a sneaking suspicion there's unstable output in the comdat group
output of MCStreamer...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197197 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r197073.
The test seems to be failing on some buildbots for unknown reasons.
Reverting until I can figure that out. If anyone's got a reproduction
(.s and .o together would be great) - I'd really appreciate it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197079 91177308-0d34-0410-b5e6-96231b3b80d8
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197073 91177308-0d34-0410-b5e6-96231b3b80d8
This removes another case of spooky action at a distance (building the
same label names in multiple places creating an implicit dependency
between those places) and helps pave the way for type units.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196617 91177308-0d34-0410-b5e6-96231b3b80d8
This is a precursor to moving type units into the correct (debug_types)
section with comdat groups and full type unit headers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196615 91177308-0d34-0410-b5e6-96231b3b80d8
This more accurately represents the actual walk - pubnames/pubtypes are
emitted into the .o, not the .dwo, and reference the skeletons not the
full units.
Use the newly established ID->index invariant to lookup the underlying
full unit to retrieve its public names and types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196601 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies reasoning about the code and enables simple navigation
from a skeleton to its full unit. (currently there are no type unit
skeletons, so the skeleton list doesn't have the same ID == index
property)
Eventually we should get rid of this ID and just store the labels we
need as the IDs are allowing this code to create difficult to
manage/understand associations (loops over non-skeletal units are
implicitly referencing their skeletal units during pub* emission, for
example). It may be necessary to have some kind of skeleton->full unit
association and a more direct pointer or similar device would be
preferable than an index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196600 91177308-0d34-0410-b5e6-96231b3b80d8
DIEs already contain references directly to their DIEAbbrev, use that
instead of looking it up based on index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196446 91177308-0d34-0410-b5e6-96231b3b80d8
While we still have a few (~4) non-trivial comments with string
concatenation, etc that should remain conditionalized, these trivial
literal comments can be simplified.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196416 91177308-0d34-0410-b5e6-96231b3b80d8
Since we always emit only one abbrevation section (shared by all the
compilation units in this module) there's no need for a separate label
at the start of each one (and we weren't using the CU ID anyway, so
there really was only one label). Use the section label instead and drop
the wholely unused debug_abbrev_end label.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196394 91177308-0d34-0410-b5e6-96231b3b80d8
Instead, reuse the same MCSymbol - this should make the code easier to
follow by avoiding hard to trace dependencies between different bits of
code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196392 91177308-0d34-0410-b5e6-96231b3b80d8
Header/cpp file rename to follow immediately - just splitting out the
commits for ease of review/reading to demonstrate that the renaming
changes are entirely mechanical.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196139 91177308-0d34-0410-b5e6-96231b3b80d8
ARanges included even extern variables referenced by pointer non-type
template parameters even though that variable isn't part of this
compilation unit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195895 91177308-0d34-0410-b5e6-96231b3b80d8
Since type units aren't in the CUMap, use the DwarfUnits list to iterate
over units for tasks such as accelerator table building.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195776 91177308-0d34-0410-b5e6-96231b3b80d8
The dumper was only dumping one pubtypes set and it was /always/ dumping
one pubtypes set even when there were zero sets. Now that the dumper
correctly dumps zero, one, or many sets, we can update this test case to
test for the absolute absence of a set rather than a bogus/accidental
zero-valued set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195706 91177308-0d34-0410-b5e6-96231b3b80d8
r195698 moved the type unit checking up into getOrCreateTypeDIE so
remove the redundant check and fold the functions back together again.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195700 91177308-0d34-0410-b5e6-96231b3b80d8
It might be possible to eventually use one data structure, but I haven't
looked at the exact criteria used for accelerator tables and pubtypes to
see if there's good reason for the differences between the two or not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195696 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids the need for an extra list of SkeletonCUs and associated
cleanup while staging things to be cleaner for further type unit
improvements.
Also hopefully fixes a memory leak introduced in r195166.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195536 91177308-0d34-0410-b5e6-96231b3b80d8
While not strictly necessary (the class has an invariant that
"setDebugInfoOffset" is called before "getDebugInfoOffset" - anyone
client that actually gets the default zero offset is buggy/broken) this
is consistent with the code as originally written and the removal of the
initialization was an accident in r195166.
Suggested by Manman Ren.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195263 91177308-0d34-0410-b5e6-96231b3b80d8
Emit DW_TAG_type_units into the debug_info section using compile unit
headers. This is bogus/unusable by debuggers, but testable and provides
more isolated review.
Subsequent patches will include support for type unit headers and
emission into the debug_types section, as well as comdat grouping the
types based on their hash. Also the CompileUnit type will be renamed
'Unit' and relevant portions pulled out into respective CompileUnit and
TypeUnit types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195166 91177308-0d34-0410-b5e6-96231b3b80d8
I hit some problems with future work due to the member subprogram of
'a_b's type having a subprogram (an implicit default ctor, !52 in the
pre-commit source) with no name. Clang now generates a name for such a
function but in this case doesn't even emit debug info for it as it is
unused (Clang never emits the body of the ctor, instead just emitting
memset if needed).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193892 91177308-0d34-0410-b5e6-96231b3b80d8
The point is to ensure that the attribute in question
(DW_AT_data_member_location) is associated with the prior tag, so ensure
that we don't see another tag starting between the intended tag and the
desired attribute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193884 91177308-0d34-0410-b5e6-96231b3b80d8
In a failed attempt to allow the gnu-public-names.ll test case to not
hardcode the size of the unit that the pubnames section referred to I've
at least managed to have unit headers and pubnames headers print out in
a similar style.
This failed to achieve the desired goal because the header in a unit
specifies the length of the unit without the length element of the
header whereas the length in the pubnames includes this element, so the
numbers are off by 4 bytes. I don't know of any arithmetic powers in
FileCheck so the test case can't simply say "CU_LENGTH + 4".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193872 91177308-0d34-0410-b5e6-96231b3b80d8
Also improve the implementation of EmitRawText(Twine) so it doesn't
bother using the SmallString buffer if the Twine is a simple StringRef
anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193378 91177308-0d34-0410-b5e6-96231b3b80d8
This may've been used at some point but the 'print' member function grew
an Indent parameter that entirely shadows this parameter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193358 91177308-0d34-0410-b5e6-96231b3b80d8
Since (as of r190716) Clang no longer emits debug info for C++ friend
declarations (and it seems GCC never has/does, which was the motivation
for the Clang change), there's no actual reachable case for implementing
the part of DWARF 4, Section 7.27 part 5 that pertains to friends.
Leave an assert here so that if/when we do have a client producing
friends and using type units, we can fill in the gap and add appropriate
(unit and feature) tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193193 91177308-0d34-0410-b5e6-96231b3b80d8
Includes a test case/FIXME demonstrating a bug/limitation in pointer to
member hashing. To be honest I'm not sure why we don't just always use
summary hashing for referenced types... but perhaps I'm missing
something.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193175 91177308-0d34-0410-b5e6-96231b3b80d8
There are several other tag types that need similar handling but to
ensure test coverage they'll be coming incrementally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193126 91177308-0d34-0410-b5e6-96231b3b80d8
This uses a map, keeping the type DIE numbering separate from the DIEs
themselves - alternatively we could do things the way GCC does if we
want to add an integer to the DIE type to record the numbering there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193105 91177308-0d34-0410-b5e6-96231b3b80d8
This allows various variables to be more self-documenting and easier to
debug by being of specific types without overlapping enum values.
Precommit review by Eric Christopher.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193091 91177308-0d34-0410-b5e6-96231b3b80d8
Found while adding type safety to the various DWARF enumerations (form,
attribute, tag, etc) that caused Clang to warn on an incompletely
covered switch. Converting the comment to a default/unreachable
uncovered this case of an unsupported form encoding. Seems we were
skipping fission strings entirely.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193089 91177308-0d34-0410-b5e6-96231b3b80d8
Makes the uses more terse and requires that they use a semicolon at the
end that helps editors indent proceeding lines correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192925 91177308-0d34-0410-b5e6-96231b3b80d8
GTest assumes the left hand side of the assert is the expectation and
the right hand side is the test result. It's easier to read gtest
failures when these things are ordered correctly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192854 91177308-0d34-0410-b5e6-96231b3b80d8
Also minor using namespace move so it's not hard-up against the function
definition and outside the namespace as is usual.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192744 91177308-0d34-0410-b5e6-96231b3b80d8
In the case (shown in the attached test) where a member function
definition was emitted into debug info the following could occur:
1) build the debug info for the member function definition
2) in (1), build the debug info for the member function declaration
3) construct and add the member function declaration DIE
4) add it to its context
5) build its context (the type it is a member of)
6) construct the members and add them to the type
7) except don't add member functions because "getOrCreateSubprogram"
adds the function to its parent anyway
8) except we're only partway through building this subprogram
declaration so it hasn't been added yet - but we returned the partially
constructed DIE (since it's already in the MDNode->DIE mapping to avoid
infinitely recursing trying to create the member function DIE)
9) once the type is constructed, add the member function to it
10) now the members are out of order (the member function being defined
is listed as the last member, even though it was declared as the first)
To avoid this, construct the context of the subprogram DIE before we
query to see if it exists. That way we never end up creating it before
creating its context and ending up in this situation.
Alternatively, the type construction that visits/builds all the members
could call something like getOrCreateSubprogram, but that doesn't ever
do the "add to context" step. Then the type building code would always
be responsible for adding members (and the subprogram "addToContextDIE"
would no-op because the context building would have added the subprogram
declaration to the type/context DIE already).
(the test cases updated were overly-sensitive to offsets or abbreviation
numbers. We don't have a nice way to make these tests more robust as yet
- multiline FileCheck matches would be required)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191939 91177308-0d34-0410-b5e6-96231b3b80d8
David Blaikie