| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 192215
|
| |
|
|
| |
llvm-svn: 192118
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 192014
|
| |
|
|
| |
llvm-svn: 192009
|
| |
|
|
| |
llvm-svn: 192005
|
| |
|
|
|
|
| |
scope, pass a scope.
llvm-svn: 192002
|
| |
|
|
| |
llvm-svn: 192000
|
| |
|
|
|
|
| |
* two actually due to some weird template thing... investigating that.
llvm-svn: 191998
|
| |
|
|
| |
llvm-svn: 191994
|
| |
|
|
|
|
| |
This has the side effect of using DW_FORM_flag_present on dwarf4 and above.
llvm-svn: 191991
|
| |
|
|
|
|
| |
a flag. No functional change.
llvm-svn: 191990
|
| |
|
|
|
|
| |
way for all platforms.
llvm-svn: 191975
|
| |
|
|
|
|
|
| |
on platforms with relocations in debug info and also temporarily
revert r191800 due to conflicts with the revert of r191792.
llvm-svn: 191967
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 191800
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and it is shared across CUs.
We add a few maps in DwarfDebug to map MDNodes for the type system to the
corresponding DIEs: MDTypeNodeToDieMap, MDSPNodeToDieMap, and
MDStaticMemberNodeToDieMap. These DIEs can be shared across CUs, that is why we
keep the maps in DwarfDebug instead of CompileUnit.
Sometimes, when we try to add an attribute to a DIE, the DIE is not yet added
to its owner yet, so we don't know whether we should use ref_addr or ref4.
We create a worklist that will be processed during finalization to add
attributes with the correct form (ref_addr or ref4).
We add addDIEEntry to DwarfDebug to be a wrapper around DIE->addValue. It checks
whether we know the correct form, if not, we update the worklist
(DIEEntryWorklist).
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.
llvm-svn: 191792
|
| |
|
|
| |
llvm-svn: 191257
|
| |
|
|
|
|
| |
checking patch until we get full dumping support.
llvm-svn: 191239
|
| |
|
|
| |
llvm-svn: 191235
|
| |
|
|
|
|
|
| |
info finalization to greatly reduce the number of fixups that the
assembler has to handle in order to improve compile time.
llvm-svn: 191119
|
| |
|
|
|
|
| |
to further work.
llvm-svn: 191113
|
| |
|
|
| |
llvm-svn: 191052
|
| |
|
|
|
|
|
|
| |
This partially reverts r190330. DIScope::getContext now returns DIScopeRef
instead of DIScope. We construct a DIScopeRef from DIScope when we are
dealing with subprogram, lexical block or name space.
llvm-svn: 190362
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In DIBuilder, the context field of a TAG_member is updated to use the
scope reference. Verifier is updated accordingly.
DebugInfoFinder now needs to generate a type identifier map to have
access to the actual scope. Same applies for BreakpointPrinter.
processModule of DebugInfoFinder is called during initialization phase
of the verifier to make sure the type identifier map is constructed early
enough.
We are now able to unique a simple class as demonstrated by the added
testing case.
llvm-svn: 190334
|
| |
|
|
|
|
|
|
|
|
|
|
| |
DIScope::getContext is a wrapper function that calls the specific getContext
method on each subclass. When we switch DIType::getContext to return DIScopeRef
instead of DIScope, DIScope::getContext can no longer return a DIScope without
a type identifier map.
DIScope::getContext is only used by DwarfDebug, so we move it to DwarfDebug
to have easy access to the type identifier map.
llvm-svn: 190330
|
| |
|
|
|
|
|
|
|
|
| |
This helper function needs the type identifier map when we switch
DIType::getContext to return DIScopeRef instead of DIScope.
Since isSubprogramContext is used by DwarfDebug only, We move it to DwarfDebug
to have easy access to the map.
llvm-svn: 190325
|
| |
|
|
|
|
|
|
| |
a DISubprogram.
Verifier is updated accordingly.
llvm-svn: 190229
|
| |
|
|
|
|
|
|
| |
a DICompositeType.
Verifier is updated accordingly.
llvm-svn: 190190
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ptr_to_member.
We introduce a new class DITypeRef that represents a reference to a DIType.
It wraps around a Value*, which can be either an identifier in MDString
or an actual MDNode. The class has a helper function "resolve" that
finds the actual MDNode for a given DITypeRef.
We specialize getFieldAs to return a field that is a reference to a
DIType. To correctly access the base type field of ptr_to_member,
getClassType now calls getFieldAs<DITypeRef> to return a DITypeRef.
Also add a typedef for DITypeIdentifierMap and a helper
generateDITypeIdentifierMap in DebugInfo.h. In DwarfDebug.cpp, we keep
a DITypeIdentifierMap and call generateDITypeIdentifierMap to actually
populate the map.
Verifier is updated accordingly.
llvm-svn: 190081
|
| |
|
|
|
|
|
|
| |
we're proposing it for DWARF5.
No functional change intended.
llvm-svn: 190074
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
dead and the rest of the compatibility should be done on a dwarf-N level.""
This reverts commit r189913.
Talked with Eric on IRC. I am going to XFAIL the failing test since it
is using what Eric described as "the member hack" which was needed on
that old GDB.
Sorry for the noise!
llvm-svn: 189914
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the rest of the compatibility should be done on a dwarf-N level."
This reverts commit r189903.
This commit broke the phase 1 buildbot for a while.
http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-nobootstrap-RAincremental/builds/6684
llvm-svn: 189913
|
| |
|
|
|
|
| |
the rest of the compatibility should be done on a dwarf-N level.
llvm-svn: 189903
|
| |
|
|
|
|
|
|
|
|
| |
when we can. Migrate from using blocks when we're adding just a
single attribute and floating point values are an unsigned, not signed,
bag of bits.
Update all test cases accordingly.
llvm-svn: 189419
|
| |
|
|
|
|
| |
can get it via the MDNode that's passed in. Save that instead.
llvm-svn: 189291
|
| |
|
|
|
|
|
|
| |
We check this in many/all other cases, just missed this one it seems.
Perhaps it'd be worth unifying this so we never emit zero-length
DW_AT_names.
llvm-svn: 188649
|
| |
|
|
|
|
|
|
| |
record type after construction
Plus a type cleanup & minor fix to enumerate members of declarations.
llvm-svn: 188577
|
| |
|
|
|
|
|
| |
be void and therefore not have a type entry. Only add the type if
it is non-void and provide a testcase.
llvm-svn: 187966
|
| |
|
|
| |
llvm-svn: 187964
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the type exists.
Fix up cases where we weren't checking for optional types and add
an assert to addType to make sure we catch this in the future.
Fix up a testcase that was using the tag for DW_TAG_array_type
when it meant DW_TAG_enumeration_type.
llvm-svn: 187963
|
| |
|
|
| |
llvm-svn: 187962
|
| |
|
|
| |
llvm-svn: 187953
|
| |
|
|
|
|
| |
The absence of members was a poor/incorrect proxy for "is definition".
llvm-svn: 187607
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type units.
Initially this support is used in the computation of an ODR checker
for C++. For now we're attaching it to the DIE, but in the future
it will be attached to the type unit.
This also starts breaking out types into the separation for type
units, but without actually splitting the DIEs.
In preparation for hashing the DIEs this adds a DIEString type
that contains a StringRef with the string contained at the label.
llvm-svn: 187213
|
| |
|
|
| |
llvm-svn: 186295
|
| |
|
|
| |
llvm-svn: 185984
|
| |
|
|
| |
llvm-svn: 185971
|