We add a map in DwarfDebug to map MDNodes that are shareable across CUs to the
corresponding DIEs: MDTypeNodeToDieMap. These DIEs can be shared across CUs,
that is why we keep the maps in DwarfDebug instead of CompileUnit.
We make the assumption that if a DIE is not added to an owner yet, we assume
it belongs to the current CU. Since DIEs for the type system are added to
their owners immediately after creation, and other DIEs belong to the current
CU, the assumption should be true.
A testing case is added to show that we only create a single DIE for a type
MDNode and we use ref_addr to refer to the type DIE.
We also add a testing case to show ref_addr relocations for non-darwin
platforms.
llvm-svn: 193779
To support ref_addr, we calculate the section offset of a DIE (i.e. offset
of a DIE from beginning of the debug info section). The Offset field in DIE
is currently CU-relative. To calculate the section offset, we add a
DebugInfoOffset field in CompileUnit to store the offset of a CU from beginning
of the debug info section. We set the value in DwarfUnits::computeSizeAndOffset
for each CompileUnit.
A helper function DIE::getCompileUnit is added to return the CU DIE that
the input DIE belongs to. We also add a map CUDieMap in DwarfDebug to help
finding the CU for a given CU DIE.
For a cross-referenced DIE, we first find the CU DIE it belongs to with
getCompileUnit, then we use CUDieMap to get the corresponding CU for the CU DIE.
Adding the section offset of the CU with the CU-relative offset of a DIE gives
us the seciton offset of the DIE.
We correctly emit ref_addr with relocation using EmitLabelPlusOffset when
doesDwarfUseRelocationsAcrossSections is true.
This commit handles the emission of DW_FORM_ref_addr when we have an attribute
with FORM_ref_addr. A follow-on patch will start using ref_addr when adding a
DIEEntry. This commit will be tested and verified in the follow-on patch.
Reviewed off-list by Eric, Thanks.
llvm-svn: 193658
after the DIE creation, we construct the context first.
Ensure that we create the context before we create a type so that we can add
the newly created type to the parent. Remove last use of addToContextOwner
now that it's not needed.
We use createAndAddDIE to wrap around "new DIE(". Now all shareable DIEs
should be added to their parents right after the creation.
Reviewed off-list by Eric, Thanks.
llvm-svn: 193657
after the DIE creation, we construct the context first.
This touches creation of namespaces and global variables. The purpose is to
handle all DIE creations similarly: constructs the context first, then creates
the DIE and immediately adds the DIE to its parent.
We use createAndAddDIE to wrap around "new DIE(".
llvm-svn: 193589
More patches will be submitted to convert "new DIE(" to use createAddAndDIE in
DwarfCompileUnit.cpp. This will simplify implementation of addDIEEntry where
we have to decide between ref4 and ref_addr, because DIEs that can be shared
across CU will be added to a CU already.
Reviewed off-list by Eric.
llvm-svn: 193567
It wraps around "new DIE(" and handles the bookkeeping part of the newly-created
DIE. It adds the DIE to its parent, and calls insertDIE if necessary. It makes
sure that bookkeeping is done at the earliest time and we should not see
parentless DIEs if all constructions of DIEs go through this helper function.
Later on, we can use an allocator for DIE allocation, and will only need to
change createAndAddDIE instead of modifying all the "new DIE(".
Reviewed off-list by Eric.
llvm-svn: 193566
Since we never insert DIE for DITemplateTypeParameter to a map, there is no need
to call getDIE in getOrCreateTemplateTypeParameterDIE. It is also renamed to
constructTemplateTypeParameterDIE to match with other construct functions
in CompileUnit.
Same applies to getOrCreateTemplateValueParameterDIE.
llvm-svn: 193287
Remove the unneeded return values from createMemberDIE, constructEnumTypeDIE,
getOrCreateTemplateTypeParameterDIE, and getOrCreateTemplateValueParameterDIE.
llvm-svn: 193285
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.
llvm-svn: 193091
With this commit, all DIEs created in CompileUnit will be added to parents
inside the same function. Also make getOrCreateTemplateType|Value functions
private.
No functionality change.
llvm-svn: 193002
like C++ should be the fully qualified names for the type.
Add a routine that does a language specific context walk to build
up the qualified name and use it when we add types/names to the
tables. Expand the gnu pubnames testcase as it's the most complex
to make sure that qualified types are also being added.
llvm-svn: 192865
1) Make sure we emit static member variables by checking
at the end of createGlobalVariableDIE rather than piecemeal
in the function.
(As a note, createGlobalVariableDIE needs rewriting.)
2) Make sure we use the definition rather than declaration DIE
for two things: a) determining linkage for gnu pubnames, and b)
as the address of the DIE for global variables.
(As a note, createGlobalVariableDIE really needs rewriting.)
Adjust the testcase to make sure we're checking the correct DIEs.
llvm-svn: 192761
Clean up creation of static member DIEs. We can create static member DIEs from
two places, so we call getOrCreateStaticMemberDIE from the two places.
getOrCreateStaticMemberDIE will get or create the context DIE first, then it
will check if the DIE already exists, if not, we create the static member DIE
and add it to the context.
Creation of static member DIEs are handled in a similar way as subprogram DIEs.
llvm-svn: 192618
is updated to use DITypeRef.
Move isUnsignedDIType and getOriginalTypeSize from DebugInfo.h to be static
helper functions in DwarfCompileUnit. We already have a static helper function
"isTypeSigned" in DwarfCompileUnit, and a pointer to DwarfDebug is added to
resolve the derived-from field. All three functions need to go across link
for derived-from fields, so we need to get hold of a type identifier map.
A pointer to DwarfDebug is also added to DbgVariable in order to resolve the
derived-from field.
Debug info verifier is updated to check a derived-from field is a TypeRef.
Verifier will not go across link for derived-from fields, in debug info finder,
we go across the link to add derived-from fields to types.
Function getDICompositeType is only used by dragonegg and since dragonegg does
not generate identifier for types, we use an empty map to resolve the
derived-from field.
When printing a derived-from field, we use DITypeRef::getName to either return
the type identifier or getName of the DIType.
A paired commit at clang is required due to changes to DIBuilder.
llvm-svn: 192018
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)
llvm-svn: 191939
DIE::addChild had a shortcircuit that silently no-op'd when a child was
readded to the same parent. This hid some quirky/redundant code in
DwarfDebug/CompileUnit. By removing that functionality and replacing it
with an assert I was able to find and cleanup those cases, mostly
centering around adding members to types in various circumstances.
1) The original oddity I noticed while working on type units (which
actually was helping me in the short term, by accident) was the
addToContextOwner call in constructTypeDIE. This call was completely
bogus (why was it only done for non-virtual types? what relevance does
that have at all) and redundant with the more uniform addToContextOwner
made in getOrCreateTypeDIE.
2) If a member function definition was visited (createSubprogramDIE), it
would attempt to build the member function declaration. The declaration
DIE would then be added to its context, but in building the context (the
type for which this function is a member) the members of the type would
be added to the type automatically, so by the time the context was
constructed, the member function was already associated with it.
3) The same as (2) but without the member function being constructed
first. Whenever a type was constructed, the members would be created and
member functions would be created by getOrCreateSubprogramDIE - this
would lead to the subprogram being added to the (incomplete) type
already, then the general member-construction code would add it again.
llvm-svn: 191928
r191052 added emitting .debug_aranges to Clang, but this
functionality is broken: it uses all MC labels added in DWARF Asm
printer, including the labels for build relocations between
different DWARF sections, like .Lsection_line or .Ldebug_loc0.
As a result, if any DIE .debug_info would contain "DW_AT_location=0x123"
attribute, .debug_aranges would also contain a range starting from 0x123,
breaking tools that rely on this section.
This patch fixes this by using only MC labels that corresponds to the
addresses in the user program.
llvm-svn: 191884
