summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* CodeGen: add missing includeSaleem Abdulrasool2014-07-141-0/+1
| | | | | | | Found during windows unwinding work. This header is indirectly included through a chain leading through Support/Win64EH.h. Explicitly include the header. NFC. llvm-svn: 212955
* Revert "Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-111-1/+2
| | | | | | | | | | | | instructions within a function, lead to the function itself."" This reverts commit r212776. Nope, still seems to be failing on the sanitizer bots... but hey, not the msan self-host anymore, it's failing in asan now. I'll start looking there next. llvm-svn: 212793
* Reapply "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instructions within a function, lead to the function itself." Committed in r212205 and reverted in r212226 due to msan self-hosting failure, I believe I've got that fixed by r212761 to Clang. Original commit message: "Originally committed in r211723, reverted in r211724 due to failure cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065), committed again in r212085 and reverted again in r212089 after fixing some other cases, such as debug info subprogram lists not keeping track of the function they represent (r212128) and then short-circuiting things like LiveDebugVariables that build LexicalScopes for functions that might not have full debug info. And again, I believe the invariant actually holds for some reasonable amount of code (but I'll keep an eye on the buildbots and see what happens... ). Original commit message: PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions." llvm-svn: 212776
* Recommit r212203: Don't try to construct debug LexicalScopes hierarchy for ↵David Blaikie2014-07-091-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | functions that do not have top level debug information. Reverted by Eric Christopher (Thanks!) in r212203 after Bob Wilson reported LTO issues. Duncan Exon Smith and Aditya Nandakumar helped provide a reduced reproduction, though the failure wasn't too hard to guess, and even easier with the example to confirm. The assertion that the subprogram metadata associated with an llvm::Function matches the scope data referenced by the DbgLocs on the instructions in that function is not valid under LTO. In LTO, a C++ inline function might exist in multiple CUs and the subprogram metadata nodes will refer to the same llvm::Function. In this case, depending on the order of the CUs, the first intance of the subprogram metadata may not be the one referenced by the instructions in that function and the assertion will fail. A test case (test/DebugInfo/cross-cu-linkonce-distinct.ll) is added, the assertion removed and a comment added to explain this situation. Original commit message: If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 212649
* Temporarily revert "Don't try to construct debug LexicalScopes hierarchy for ↵Eric Christopher2014-07-031-9/+1
| | | | | | | | functions that do not have top level debug information." as it appears to be breaking some LTO constructs. This reverts commit r212203. llvm-svn: 212298
* Revert "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-021-1/+2
| | | | | | | | | | | | instructions within a function, lead to the function itself." This reverts commit r212205. Reverting this again, still seeing crashes when building compiler-rt... Sorry for the continued noise, not sure why I'm failing to reproduce this locally. llvm-svn: 212226
* DebugInfo: Ensure that all debug location scope chains from instructions ↵David Blaikie2014-07-021-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | within a function, lead to the function itself. Originally committed in r211723, reverted in r211724 due to failure cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065), committed again in r212085 and reverted again in r212089 after fixing some other cases, such as debug info subprogram lists not keeping track of the function they represent (r212128) and then short-circuiting things like LiveDebugVariables that build LexicalScopes for functions that might not have full debug info. And again, I believe the invariant actually holds for some reasonable amount of code (but I'll keep an eye on the buildbots and see what happens... ). Original commit message: PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions. llvm-svn: 212205
* Don't try to construct debug LexicalScopes hierarchy for functions that do ↵David Blaikie2014-07-021-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | not have top level debug information. If a function isn't actually in a CU's subprogram list in the debug info metadata, ignore all the DebugLocs and don't try to build scopes, track variables, etc. While this is possibly a minor optimization, it's also a correctness fix for an incoming patch that will add assertions to LexicalScopes and the debug info verifier to ensure that all scope chains lead to debug info for the current function. Fix up a few test cases that had broken/incomplete debug info that could violate this constraint. Add a test case where this occurs by design (inlining a debug-info-having function in an attribute nodebug function - we want this to work because /if/ the nodebug function is then inlined into a debug-info-having function, it should be fine (and will work fine - we just stitch the scopes up as usual), but should the inlining not happen we need to not assert fail either). llvm-svn: 212203
* Revert "DebugInfo: Ensure that all debug location scope chains from ↵David Blaikie2014-07-011-1/+2
| | | | | | | | | | | instructions within a function, lead to the function itself." This reverts commit r212085. This breaks the sanitizer bot... & I thought I'd tried pretty hard not to do that. Guess I need to try harder. llvm-svn: 212089
* DebugInfo: Ensure that all debug location scope chains from instructions ↵David Blaikie2014-07-011-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | within a function, lead to the function itself. Originally committed in r211723, reverted in r211724 due to failure cases found and fixed (ArgumentPromotion: r211872, Inlining: r212065), and I now believe the invariant actually holds for some reasonable amount of code (but I'll keep an eye on the buildbots and see what happens... ). Original commit message: PR20038: DebugInfo: Inlined call sites where the caller has debug info but the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions. llvm-svn: 212085
* Revert "Revert "Revert "PR20038: DebugInfo: Inlined call sites where the ↵David Blaikie2014-06-271-1/+2
| | | | | | | | | | | caller has debug info but the call itself has no debug location.""" Reverting this again, didn't mean to commit it - while r211872 fixes one of the issues here, there are still others to figure out and address. This reverts commit r211871. llvm-svn: 211873
* Revert "Revert "PR20038: DebugInfo: Inlined call sites where the caller has ↵David Blaikie2014-06-271-2/+1
| | | | | | | | debug info but the call itself has no debug location."" This reverts commit r211724. llvm-svn: 211871
* Revert "PR20038: DebugInfo: Inlined call sites where the caller has debug ↵David Blaikie2014-06-251-1/+2
| | | | | | | | | | | info but the call itself has no debug location." This reverts commit r211723. Breaks the ASan/compiler-rt build... guess I didn't test very far at all :/. llvm-svn: 211724
* PR20038: DebugInfo: Inlined call sites where the caller has debug info but ↵David Blaikie2014-06-251-2/+1
| | | | | | | | | | | | | | | | | | the call itself has no debug location. This situation does bad things when inlined, so I've fixed Clang not to produce inlinable call sites without locations when the caller has debug info (in the one case where I could find that this occurred). This updates the PR20038 test case to be what clang now produces, and readds the assertion that had to be removed due to this bug. I've also beefed up the debug info verifier to help diagnose these issues in the future, and I hope to add checks to the inliner to just assert-fail if it encounters this situation. If, in the future, we decide we have to cope with this situation, the right thing to do is probably to just remove all the DebugLocs from the inlined instructions. llvm-svn: 211723
* DebugInfo: Fission: Ensure the address pool entries for location lists are ↵David Blaikie2014-06-191-1/+1
| | | | | | | | | emitted. The address pool was being emitted before location lists. The latter could add more entries to the pool which would be lost/never emitted. llvm-svn: 211284
* Emit DWARF3 call frame information when DWARF3+ debug info is requestedOliver Stannard2014-06-191-0/+2
| | | | | | | | | | | | | | | | Currently, llvm always emits a DWARF CIE with a version of 1, even when emitting DWARF 3 or 4, which both support CIE version 3. This patch makes it emit the newer CIE version when we are emitting DWARF 3 or 4. This will not reduce compatibility, as we already emit other DWARF3/4 features, and is worth doing as the DWARF3 spec removed some ambiguities in the interpretation of call frame information. It also fixes a minor bug where the "return address" field of the CIE was encoded as a ULEB128, which is only valid when the CIE version is 3. There are no test changes for this, because (as far as I can tell) none of the platforms that we test have a return address register with a DWARF register number >127. llvm-svn: 211272
* Move -dwarf-version to an MC level command line option so it'sEric Christopher2014-06-191-4/+1
| | | | | | | used by all of the MC level tools and codegen. Fix up all uses in the compiler to use this and set it on the context accordingly. llvm-svn: 211257
* PR20038: DebugInfo missing DIEs for some concrete variables.David Blaikie2014-06-151-0/+3
| | | | | | | | I haven't nailed this down entirely, but this is about as small of a test case as I can seem to construct and adequately demonstrates the crasher. I'll continue investigating the root cause/fix(es). llvm-svn: 210993
* DebugInfo: Remove some extra handling of abstract variables and instead rely ↵David Blaikie2014-06-131-25/+23
| | | | | | | | | | | | | | | solely on the delayed handling introduced in r210946 Now that we handle finding abstract variables at the end of the module, remove the upfront handling and just ensure the abstract variable is built when necessary. In theory we could have a split implementation, where inlined variables are immediately constructed referencing the abstract definition, and concrete variables are delayed - but let's go with one solution for now unless there's a reason not to. llvm-svn: 210961
* DebugInfo: Reference abstract definitions from variables in concrete ↵David Blaikie2014-06-131-1/+6
| | | | | | | | | | | | definitions that preceed their first inline definition. Rather than relying on abstract variables looked up at the time the concrete variable is created, look them up at the end of the module to ensure they're referenced even if they're created after the concrete definition. This completes/matches the work done in r209677 to handle this for the subprograms themselves. llvm-svn: 210946
* DwarfDebug::getExistingAbstractVariable: constify an existing reference ↵David Blaikie2014-06-131-1/+1
| | | | | | parameter that didn't need to be mutated. llvm-svn: 210944
* DebugInfo: Following up to r209677, refactor local variable emission to ↵David Blaikie2014-06-131-11/+30
| | | | | | | | | | | | | | | | delay the choice between emitting the definition attributes or using DW_AT_abstract_definition This doesn't fix the abstract variable handling yet, but it introduces a similar delay mechanism as was added for subprograms, causing DW_AT_location to be reordered to the beginning of the attribute list for local variables, and fixes all the test fallout for that. A subsequent commit will remove the abstract variable handling in DbgVariable and just do the abstract variable lookup at module end to ensure that abstract variables introduced after their concrete counterparts are appropriately referenced by the concrete variable. llvm-svn: 210943
* DebugInfo: Use the scope of the function declaration, if any, to name a ↵David Blaikie2014-06-061-4/+2
| | | | | | | | | | function in DWARF pubnames This ensures that member functions, for example, are entered into pubnames with their fully qualified name, rather than inside the global namespace. llvm-svn: 210379
* Fix null dereference with -debug-only=dwarfdebugAlexey Samsonov2014-06-051-2/+5
| | | | llvm-svn: 210299
* DebugInfo: Reuse existing LexicalScope to retrieve the scope's MDNode, ↵David Blaikie2014-06-051-6/+2
| | | | | | | | | rather than looking it up through the DebugLoc. No functional change intended, just streamlines the abstract variable lookup/construction to use a common entry point. llvm-svn: 210234
* DebugInfo: Roll argument insertion into variable insertion to ensure ↵David Blaikie2014-06-051-6/+5
| | | | | | | | arguments are correctly handled in all cases. No functional change intended. llvm-svn: 210233
* PR19388: DebugInfo: Emit dead arguments in their originally declared order.David Blaikie2014-06-051-5/+6
| | | | | | | | | | | | | | | | | | | | | | | Unused arguments were not being added to the argument list, but instead treated as arbitrary scope variables. This meant they weren't carefully added in the original argument order. In this particular example, though, it turns out the argument is only /mostly/ unused (well, actually it's entirely used, but in a specific way). It's a struct that, due to ABI reasons, is decomposed into chunks (exactly one chunk, since it has one member) and then passed. Since only one of those chunks is used (SROA, etc, kill the original reconstitution code) we don't have a location to describe the whole variable. In this particular case, since the struct consists of just the one int, once we have partial location information, this should have a location that describes the entire variable (since the piece is the entirety of the object). And at some point we'll need to describe the location of even /entirely/ unused arguments so that they can at least be printed on function entry. llvm-svn: 210231
* DebugInfo: Reapply r209984 (reverted in r210143), asserting that abstract ↵David Blaikie2014-06-041-9/+34
| | | | | | | | | | | | | | | | | DbgVariables have DIEs. Abstract variables within abstract scopes that are entirely optimized away in their first inlining are omitted because their scope is not present so the variable is never created. Instead, we should ensure the scope is created so the variable can be added, even if it's been optimized away in its first inlining. This fixes the incorrect debug info in missing-abstract-variable.ll (added in r210143) and passes an asserts self-hosting build, so hopefully there's not more of these issues left behind... *fingers crossed*. llvm-svn: 210221
* DebugInfo: Assert that DbgVariables have associated DIEsDavid Blaikie2014-06-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 llvm-svn: 209984
* Roll DbgVariable::setMInsn into the constructor. No functional changes.Adrian Prantl2014-05-301-4/+2
| | | | llvm-svn: 209920
* Debug Info: Remove unused code. The MInsn of an _abstract_ variable isAdrian Prantl2014-05-291-2/+0
| | | | | | | never used again and updating the abstract variable for each inlined instance of it was questionable in the first place. llvm-svn: 209829
* Change representation of instruction ranges where variable is accessible.Alexey Samsonov2014-05-271-46/+32
| | | | | | | | | | | | | | Use more straightforward way to represent the set of instruction ranges where the location of a user variable is defined - vector of pairs of instructions (defining start/end of each range), instead of a flattened vector of instructions where some instructions are supposed to start the range, and the rest are supposed to "clobber" it. Simplify the code which generates actual .debug_loc entries. No functionality change. llvm-svn: 209698
* Factor out looking for prologue end into a functionAlexey Samsonov2014-05-271-12/+12
| | | | llvm-svn: 209697
* Don't pre-populate the set of keys in the map with variable locations history.Alexey Samsonov2014-05-271-11/+2
| | | | | | | | | | Current implementation of calculateDbgValueHistory already creates the keys in the expected order (user variables are listed in order of appearance), and should do so later by contract. No functionality change. llvm-svn: 209690
* DebugInfo: Simplify solution to avoid DW_AT_artificial on inlined parameters.David Blaikie2014-05-271-6/+1
| | | | | | | Originally committed in r207717, I clearly didn't look very closely at the code to understand how existing things were working... llvm-svn: 209680
* DebugInfo: Create abstract function definitions even when concrete ↵David Blaikie2014-05-271-46/+35
| | | | | | | | | | | | | | | definitions preceed inline definitions. After much puppetry, here's the major piece of the work to ensure that even when a concrete definition preceeds all inline definitions, an abstract definition is still created and referenced from both concrete and inline definitions. Variables are still broken in this case (see comment in dbg-value-inlined-parameter.ll test case) and will be addressed in follow up work. llvm-svn: 209677
* DebugInfo: Avoid an extra map lookup when finding abstract subprogram DIEs.David Blaikie2014-05-271-1/+1
| | | | llvm-svn: 209676
* DebugInfo: Lazily construct subprogram definition DIEs.David Blaikie2014-05-271-10/+22
| | | | | | | | | | | | | | | | A further step to correctly emitting concrete out of line definitions preceeding inlined instances of the same program. To do this, emission of subprograms must be delayed until required since we don't know which (abstract only (if there's no out of line definition), concrete only (if there are no inlined instances), or both) DIEs are required at the start of the module. To reduce the test churn in the following commit that actually fixes the bug, this commit introduces the lazy DIE construction and cleans up test cases that are impacted by the changes in the resulting DIE ordering. llvm-svn: 209675
* DebugInfo: Lazily attach definition attributes to definitions.David Blaikie2014-05-271-0/+21
| | | | | | | | | | | | | | | | | | | | | This is a precursor to fixing inlined debug info where the concrete, out-of-line definition may preceed any inlined usage. To cope with this, the attributes that may appear on the concrete definition or the abstract definition are delayed until the end of the module. Then, if an abstract definition was created, it is referenced (and no other attributes are added to the out-of-line definition), otherwise the attributes are added directly to the out-of-line definition. In a couple of cases this causes not just reordering of attributes, but reordering of types. When the creation of the attribute is delayed, if that creation would create a type (such as for a DW_AT_type attribute) then other top level DIEs may've been constructed during the delay, causing the referenced type to be created and added after those intervening DIEs. In the extreme case, in cross-cu-inlining.ll, this actually causes the DW_TAG_basic_type for "int" to move from one CU to another. llvm-svn: 209674
* DebugInfo: Put concrete definitions referencing abstract definitions in the ↵David Blaikie2014-05-231-1/+3
| | | | | | | | | | | | | | | | | | | same scope as the abstract definition. This seems like a simple cleanup/improved consistency, but also helps lay the foundation to fix the bug mentioned in the test case: concrete definitions preceeding any inlined usage aren't properly split into concrete + abstract (because they're not known to need it until it's too late). Once we start deferring this choice until later, we won't have the choice to put concrete definitions for inlined subroutines in a different scope from concrete definitions for non-inlined subroutines (since we won't know at time-of-construction which one it'll be). This change brings those two cases into alignment ahead of that future chaneg/fix. llvm-svn: 209547
* Add FIXME comment based on code review feedback by Hal Finkel on r209338David Blaikie2014-05-231-0/+2
| | | | llvm-svn: 209529
* Rename a couple of variables to be more accurate.David Blaikie2014-05-231-8/+8
| | | | | | | | It's not really a "ScopeDIE", as such - it's the abstract function definition's DIE. And we usually use "SP" for subprograms, rather than "Sub". llvm-svn: 209499
* DebugInfo: Fix cross-CU references for scopes (and variables within those ↵David Blaikie2014-05-231-3/+4
| | | | | | | | scopes) in abstract definitions of cross-CU inlined functions Found by Adrian Prantl during post-commit review of r209335. llvm-svn: 209498
* DebugInfo: Simplify dead variable collection slightly.David Blaikie2014-05-221-3/+1
| | | | | | | | constructSubprogramDIE was already called for every subprogram in every CU when the module was started - there's no need to call it again at module finalization. llvm-svn: 209372
* Revert "DebugInfo: Don't put fission type units in comdat sections."David Blaikie2014-05-211-14/+10
| | | | | | | | | This reverts commit r208930, r208933, and r208975. It seems not all fission consumers are ready to handle this behavior. Reverting until tools are brought up to spec. llvm-svn: 209338
* DebugInfo: Use the SPMap to find the parent CU of inlined functions as they ↵David Blaikie2014-05-211-13/+11
| | | | | | | | | | | | | | | | may not be in the current CU Committed in r209178 then reverted in r209251 due to LTO breakage, here's a proper fix for the case of the missing subprogram DIE. The DIEs were there, just in other compile units. Using the SPMap we can find the right compile unit to search for and produce cross-unit references to describe this kind of inlining. One existing test case needed to be updated because it had a function that wasn't in the CU's subprogram list, so it didn't appear in the SPMap. llvm-svn: 209335
* DebugInfo: Ensure concrete out of line variables from inlined functions ↵David Blaikie2014-05-211-20/+25
| | | | | | reference their abstract origins. llvm-svn: 209327
* Revert "DebugInfo: Assume all subprogram DIEs have been created before any ↵David Blaikie2014-05-201-5/+5
| | | | | | | | | | | | | | abstract subprograms are constructed." This reverts commit r209178. This seems to be asserting in an LTO build on some internal Apple buildbots. No upstream reproduction (and I don't have an LLVM-aware gold built right now to reproduce it personally) but it's a small patch & the failure's semi-plausible so I'm going to revert first while I try to reproduce this. llvm-svn: 209251
* Rewrite calculateDbgValueHistory to make it (hopefully) more transparent.Alexey Samsonov2014-05-201-3/+3
| | | | | | | | | | | | | | | | | | | | | | This change preserves the original algorithm of generating history for user variables, but makes it more clear. High-level description of algorithm: Scan all the machine basic blocks and machine instructions in the order they are emitted to the object file. Do the following: 1) If we see a DBG_VALUE instruction, add it to the history of the corresponding user variable. Keep track of all user variables, whose locations are described by a register. 2) If we see a regular instruction, look at all the registers it clobbers, and terminate the location range for all variables described by these registers. 3) At the end of the basic block, terminate location ranges for all user variables described by some register. Although this change shouldn't be user-visible (the contents of .debug_loc section should be the same), it changes some internal assumptions about the set of instructions used to track the variable locations. Watching the bots. llvm-svn: 209225
* DebugInfo: Emit function definitions within their namespace scope.David Blaikie2014-05-201-22/+0
| | | | | | | | This workaround (presumably for ancient GDB) doesn't appear to be required (GDB 7.5 seems to tolerate function definition DIEs in namespace scope just fine). llvm-svn: 209189
OpenPOWER on IntegriCloud