This patch fixes an old FIXME by creating a MCTargetStreamer interface
and moving the target specific functions for ARM, Mips and PPC to it.
The ARM streamer is still declared in a common place because it is
used from lib/CodeGen/ARMException.cpp, but the Mips and PPC are
completely hidden in the corresponding Target directories.
I will send an email to llvmdev with instructions on how to use this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192181 91177308-0d34-0410-b5e6-96231b3b80d8
When MC was first added, targets could use hasRawTextSupport to keep features
working before they were added to the MC interface.
The design goal of MC is to provide an uniform api for printing assembly and
object files. Short of relaxations and other corner cases, a object file is
just another representation of the assembly.
It was never the intention that targets would keep doing things like
if (hasRawTextSupport())
Set flags in one way.
else
Set flags in another way.
When they do that they create two code paths and the object file is no longer
just another representation of the assembly. This also then requires testing
with llc -filetype=obj, which is extremelly brittle.
This patch removes some of these hacks by replacing them with smaller ones.
The ARM flag setting is trivial, so I just moved it to the constructor. For
Mips, the patch adds two temporary hack directives that allow the assembly
to represent the same things as the object file was already able to.
The hope is that the mips developers will replace the hack directives with
the same ones that gas uses and drop the -print-hack-directives flag.
I will also try to implement a target streamer interface, so that we can
move this out of the common code.
In summary, for any new work, two rules of the thumb are
* Don't use "llc -filetype=obj" in tests.
* Don't add calls to hasRawTextSupport.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192035 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192018 91177308-0d34-0410-b5e6-96231b3b80d8
on platforms with relocations in debug info and also temporarily
revert r191800 due to conflicts with the revert of r191792.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191967 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
Changed the dwarf aranges code to not use getLabelEndName, as it turns out it's not reliable to call that given user-defined section names. Section names can have characters in that aren't representable as symbol names.
The dwarf-aranges test case has been updated to include a special character, to check this.
This fixes pr17416.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191932 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191928 91177308-0d34-0410-b5e6-96231b3b80d8
going to be empty. This is particularly important for the gnu
pubnames case since we're emitting a relocation to the section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191915 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191884 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191800 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191792 91177308-0d34-0410-b5e6-96231b3b80d8
SEC_OFFSET from the beginning of the section so go ahead and emit
a label at the beginning of each one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191710 91177308-0d34-0410-b5e6-96231b3b80d8
a) Make sure we are emitting the correct section in our section labels
when we begin the module.
b) Make sure we are emitting the correct pubtypes section in the
presence of gnu pubtypes.
c) For C++ struct, union, class, and enumeration types are default
external.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191225 91177308-0d34-0410-b5e6-96231b3b80d8
The size of common symbols is now tracked correctly, so they can be listed in the arange section without needing knowledge of other following symbols.
.comm (and .lcomm) do not indicate to the system assembler any particular section to use, so we have to treat them as having no section.
Test case update to account for this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191210 91177308-0d34-0410-b5e6-96231b3b80d8
info finalization to greatly reduce the number of fixups that the
assembler has to handle in order to improve compile time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191119 91177308-0d34-0410-b5e6-96231b3b80d8
This was previously invoking UB by passing a user-defined type to
format. Thanks to Jordan Rose for pointing this out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191060 91177308-0d34-0410-b5e6-96231b3b80d8
Based on code review feedback from Eric Christopher, unshifting these
constants as they can appear in the gdb_index itself, shifted a further
24 bits. This means that keeping them preshifted is a bit inflexible, so
let's not do that.
Given the motivation, wrap up some nicer enums, more type safety, and
some utility functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191035 91177308-0d34-0410-b5e6-96231b3b80d8
Names open to bikeshedding. Could switch back to the constants being
unshifted, but this way seems a bit easier to work with.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191025 91177308-0d34-0410-b5e6-96231b3b80d8
