summaryrefslogtreecommitdiffstats
path: root/llvm/test/DebugInfo/X86
Commit message (Collapse)AuthorAgeFilesLines
...
* Avoid hardcoding PC addresses in a dwarf testVedant Kumar2018-10-051-4/+4
| | | | | | | | The PCs appear to vary from builder-to-builder: http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/20053 llvm-svn: 343886
* [DebugInfo] Add support for DWARF5 call site-related attributesVedant Kumar2018-10-051-0/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DWARF v5 introduces DW_AT_call_all_calls, a subprogram attribute which indicates that all calls (both regular and tail) within the subprogram have call site entries. The information within these call site entries can be used by a debugger to populate backtraces with synthetic tail call frames. Tail calling frames go missing in backtraces because the frame of the caller is reused by the callee. Call site entries allow a debugger to reconstruct a sequence of (tail) calls which led from one function to another. This improves backtrace quality. There are limitations: tail recursion isn't handled, variables within synthetic frames may not survive to be inspected, etc. This approach is not novel, see: https://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=jelinek.pdf This patch adds an IR-level flag (DIFlagAllCallsDescribed) which lowers to DW_AT_call_all_calls. It adds the minimal amount of DWARF generation support needed to emit standards-compliant call site entries. For easier deployment, when the debugger tuning is LLDB, the DWARF requirement is adjusted to v4. Testing: Apart from check-{llvm, clang}, I built a stage2 RelWithDebInfo clang binary. Its dSYM passed verification and grew by 1.4% compared to the baseline. 151,879 call site entries were added. rdar://42001377 Differential Revision: https://reviews.llvm.org/D49887 llvm-svn: 343883
* Fix dwarf-no-source-loc.ll path separator on WindowsReid Kleckner2018-10-051-1/+1
| | | | llvm-svn: 343880
* DwarfDebug: Pick next location in case of missing location at block beginMatthias Braun2018-10-052-6/+79
| | | | | | | | | | | | | | | | | Context: Compiler generated instructions do not have a debug location assigned to them. However emitting 0-line records for all of them bloats the line tables for very little benefit so we usually avoid doing that. Not emitting anything will lead to the previous debug location getting applied to the locationless instructions. This is not desirable for block begin and after labels. Previously we would emit simply emit line-0 records in this case, this patch changes the behavior to do a forward search for a debug location in these cases before emitting a line-0 record to further reduce line table bloat. Inspired by the discussion in https://reviews.llvm.org/D52862 llvm-svn: 343874
* Emit template type and value parameter DIEs for template variables.Matthew Voss2018-10-031-57/+77
| | | | | | | | | | | | | | | | | | | Summary: Ensure the TemplateParam attribute of the DIGlobalVariable node is translated into the proper DIEs. Resolves https://bugs.llvm.org/show_bug.cgi?id=22119 Reviewers: dblaikie, probinson, aprantl, JDevlieghere, clayborg, whitequark, deadalnix Reviewed By: dblaikie Subscribers: llvm-commits Tags: #debug-info Differential Revision: https://reviews.llvm.org/D52057 llvm-svn: 343706
* Relax dbg-declare-inalloca.ll test moreReid Kleckner2018-10-021-1/+1
| | | | | | | We don't need to match the precise type index number here. It's not important. The type name is what matters to make this test useful. llvm-svn: 343642
* [CodeView] Try fixing DebugInfo/X86/dbg-declare-inalloca.llFangrui Song2018-10-021-1/+2
| | | | llvm-svn: 343639
* Revert "X86, AArch64, ARM: Do not attach debug location to spill/reload ↵Matt Morehouse2018-10-022-3/+2
| | | | | | | | instructions" This reverts r343520 due to breakage of HWASan tests on Android. llvm-svn: 343616
* [codeview] Emit S_FRAMEPROC and use S_DEFRANGE_FRAMEPOINTER_RELReid Kleckner2018-10-011-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change, LLVM would always describe locals on the stack as being relative to some specific register, RSP, ESP, EBP, ESI, etc. Variables in stack memory are pretty common, so there is a special S_DEFRANGE_FRAMEPOINTER_REL symbol for them. This change uses it to reduce the size of our debug info. On top of the size savings, there are cases on 32-bit x86 where local variables are addressed from ESP, but ESP changes across the function. Unlike in DWARF, there is no FPO data to describe the stack adjustments made to push arguments onto the stack and pop them off after the call, which makes it hard for the debugger to find the local variables in frames further up the stack. To handle this, CodeView has a special VFRAME register, which corresponds to the $T0 variable set by our FPO data in 32-bit. Offsets to local variables are instead relative to this value. This is part of PR38857. Reviewers: hans, zturner, javed.absar Subscribers: aprantl, hiraditya, JDevlieghere, llvm-commits Differential Revision: https://reviews.llvm.org/D52217 llvm-svn: 343543
* X86, AArch64, ARM: Do not attach debug location to spill/reload instructionsMatthias Braun2018-10-012-2/+3
| | | | | | | | | | | Spill/reload instructions are artificially generated by the compiler and have no relation to the original source code. So the best thing to do is not attach any debug location to them (instead of just taking the next debug location we find on following instructions). Differential Revision: https://reviews.llvm.org/D52125 llvm-svn: 343520
* [DebugInfo] Do not generate address info for removed debug labels.Hsiangkai Wang2018-09-261-0/+39
| | | | | | | | | | | | | | | In some senario, LLVM will remove llvm.dbg.labels in IR. For example, when the labels are in unreachable blocks, these labels will not be generated in LLVM IR. In the case, these debug labels will have address zero as their address. It is not legal address for debugger to set breakpoints or query sources. So, the patch inhibits the address info (DW_AT_low_pc) of removed labels. Fix build failed in BuildBot, clang-stage1-cmake-RA-incremental, on macOS. Differential Revision: https://reviews.llvm.org/D51908 llvm-svn: 343062
* [DWARF] - Emit the correct value for DW_AT_addr_base.George Rimar2018-09-202-1/+2
| | | | | | | | | | | | | | Currently, we emit DW_AT_addr_base that points to the beginning of the .debug_addr section. That is not correct for the DWARF5 case because address table contains the header and the attribute should point to the first entry following the header. This is currently the reason why LLDB does not work with such executables correctly. Patch fixes the issue. Differential revision: https://reviews.llvm.org/D52168 llvm-svn: 342635
* [X86] Handle COPYs of physregs better (regalloc hints)Simon Pilgrim2018-09-193-5/+6
| | | | | | | | | | | | | | Enable enableMultipleCopyHints() on X86. Original Patch by @jonpa: While enabling the mischeduler for SystemZ, it was discovered that for some reason a test needed one extra seemingly needless COPY (test/CodeGen/SystemZ/call-03.ll). The handling for that is resulted in this patch, which improves the register coalescing by providing not just one copy hint, but a sorted list of copy hints. On SystemZ, this gives ~12500 less register moves on SPEC, as well as marginally less spilling. Instead of improving just the SystemZ backend, the improvement has been implemented in common-code (calculateSpillWeightAndHint(). This gives a lot of test failures, but since this should be a general improvement I hope that the involved targets will help and review the test updates. Differential Revision: https://reviews.llvm.org/D38128 llvm-svn: 342578
* Revert "[DWARF] reposting r342048, which was reverted in r342056 due to ↵Alexander Kornienko2018-09-172-26/+4
| | | | | | | | | buildbot errors. Adjusted 2 test cases for ARM and darwin and fixed a bug with the original change in dsymutil." This reverts commit r342218. Due to a number of failures under TSAN. An isolated test case is being worked on. llvm-svn: 342399
* Fix debug info for SelectionDAG legalization of DAG nodes with two results.Adrian Prantl2018-09-141-0/+47
| | | | | | | | | | | | | | | | This patch fixes the debug info handling for SelectionDAG legalization of DAG nodes with two results. When an replaced SDNode has more than one result, transferDbgValues was always copying the SDDbgValue from the first result and attaching them to all members. In reality SelectionDAG::ReplaceAllUsesWith() is given an array of SDNodes (though the type signature doesn't make this obvious (cf. the call site code in ReplaceNode()). rdar://problem/44162227 Differential Revision: https://reviews.llvm.org/D52112 llvm-svn: 342264
* [DWARF] reposting r342048, which was reverted in r342056 due to buildbot Wolfgang Pieb2018-09-142-4/+26
| | | | | | | | errors. Adjusted 2 test cases for ARM and darwin and fixed a bug with the original change in dsymutil. llvm-svn: 342218
* [MC/Dwarf] Unclamp DWARF linetables format on Darwin.Jonas Devlieghere2018-09-132-4/+4
| | | | | | | | | | | In r319995, we fixed the line table format to version 2 on Darwin because dsymutil didn't yet understand the new format which caused test failures for the LLDB bots. This has been resolved in the meantime so there's no reason to keep this limitation. rdar://problem/35968332 llvm-svn: 342136
* Reverting r342048, which caused UBSan failures in dsymutil.Wolfgang Pieb2018-09-122-26/+4
| | | | llvm-svn: 342056
* [DWARF] Refactoring range list dumping to fold DWARF v4 functionality into ↵Wolfgang Pieb2018-09-122-4/+26
| | | | | | | | | | | | | v5 handling Eliminating some duplication of rangelist dumping code at the expense of some version-dependent code in dump and extract routines. Reviewer: dblaikie, JDevlieghere, vleschuk Differential revision: https://reviews.llvm.org/D51081 llvm-svn: 342048
* [DebugInfo] Normalize common kinds of DWARF sub-expressions.Jonas Devlieghere2018-09-058-30/+28
| | | | | | | | | | | | Normalize common kinds of DWARF sub-expressions to make debug info encoding a bit more compact: DW_OP_constu [X < 32] -> DW_OP_litX DW_OP_constu [all ones] -> DW_OP_lit0, DW_OP_not (64-bit only) Differential revision: https://reviews.llvm.org/D51640 llvm-svn: 341457
* [DebugInfo] Fix bug in LiveDebugVariables.Hsiangkai Wang2018-09-051-0/+53
| | | | | | | | | | | | | | | In lib/CodeGen/LiveDebugVariables.cpp, it uses std::prev(MBBI) to get DebugValue's SlotIndex. However, the previous instruction may be also a debug instruction. It could not use a debug instruction to query SlotIndex in mi2iMap. Scan all debug instructions and use the first debug instruction to query SlotIndex for following debug instructions. Only handle DBG_VALUE in handleDebugValue(). Differential Revision: https://reviews.llvm.org/D50621 llvm-svn: 341446
* Revert "[DebugInfo] Fix bug in LiveDebugVariables."Hsiangkai Wang2018-09-021-51/+0
| | | | | | | | | This reverts commit 8f548ff2a1819e1bc051e8218584f1a3d2cf178a. buildbot failure in LLVM on clang-ppc64be-linux http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/19765 llvm-svn: 341290
* [DebugInfo] Fix bug in LiveDebugVariables.Hsiangkai Wang2018-09-021-0/+51
| | | | | | | | | | | | | | | In lib/CodeGen/LiveDebugVariables.cpp, it uses std::prev(MBBI) to get DebugValue's SlotIndex. However, the previous instruction may be also a debug instruction. It could not use a debug instruction to query SlotIndex in mi2iMap. Scan all debug instructions and use the first debug instruction to query SlotIndex for following debug instructions. Only handle DBG_VALUE in handleDebugValue(). Differential Revision: https://reviews.llvm.org/D50621 llvm-svn: 341289
* Clarify comment in the string-offsets-table-order.ll testPavel Labath2018-08-281-1/+3
| | | | llvm-svn: 340826
* DebugInfo: Fix skipping CUs in DWARFv5 debug_names tableDavid Blaikie2018-08-241-27/+45
| | | | | | | | | | My previoust test case had skipped CUs from one TU out of a two-TU LTO scenario, which meant the CU index wasn't needed (as it was unambiguous which CU a table entry applied to) - expanding the test to use 3 TUs, skipping one (so long as it's not the last one) shows the indexes are miscomputed. Fix that with a little indirection for the index. llvm-svn: 340646
* DebugInfo: Improve debug location mergingDavid Blaikie2018-08-231-0/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a set of related bugs: * Considering two locations as equivalent when their lines are the same but their scopes are different causes erroneous debug info that attributes a commoned call to be attributed to one of the two calls it was commoned from. * The previous code to compute a new location's scope was inaccurate and would use the inlinedAt that was the /parent/ of the inlinedAt that is the nearest common one, and also used that parent scope instead of the nearest common scope. * Not generating new locations generally seemed like a lower quality choice There was some risk that generating more new locations could hurt object size by making more fine grained line table entries, but it looks like that was offset by the decrease in line table (& address & ranges) size caused by more accurately computing the scope - which likely lead to fewer range entries (more contiguous ranges) & reduced size that way. All up with these changes I saw minor reductions (-1.21%, -1.77%) in .rela.debug_ranges and .rela.debug_addr (in a fission, compressed debug info build) as well as other minor size changes (generally reductinos) across the board (-1.32% debug_info.dwo, -1.28% debug_loc.dwo). Measured in an optimized (-O2) build of the clang binary. If you are investigating a size regression in an optimized debug builds, this is certainly a patch to look into - and I'd be happy to look into any major regressions found & see what we can do to address them. llvm-svn: 340583
* Avoid dbg.value use-before-def in a few tests (NFC)Vedant Kumar2018-08-212-4/+4
| | | | | | | | | | This is preparation for landing a use-before-def verifier for debug intrinsics (D46100). As a drive-by, remove `tail` from debug intrinsic calls because it doesn't mean anything in that context. llvm-svn: 340366
* Remove a hardcoded address in test/DebugInfo/X86/vla-multi.llVedant Kumar2018-08-171-2/+2
| | | | | | This relaxes a test to make it less brittle. llvm-svn: 340068
* DebugInfo: Remove command line (& target-based) disabling of pubnames in ↵David Blaikie2018-08-162-34/+3
| | | | | | | | | favor of metadata Now that Clang disables NVPTX pubnames via metadata there's no need for this fallback to target detection in the backend. llvm-svn: 339970
* DebugInfo: Add metadata support for disabling DWARF pub sectionsDavid Blaikie2018-08-169-7/+110
| | | | | | | | | | | | | | | | | | | | | | | In cases where the debugger load time is a worthwhile tradeoff (or less costly - such as loading from a DWP instead of a variety of DWOs (possibly over a high-latency/distributed filesystem)) against object file size, it can be reasonable to disable pubnames and corresponding gdb-index creation in the linker. A backend-flag version of this was implemented for NVPTX in D44385/r327994 - which was fine for NVPTX which wouldn't mix-and-match CUs. Now that it's going to be a user-facing option (likely powered by "-gno-pubnames", the same as GCC) it should be encoded in the DICompileUnit so it can vary per-CU. After this, likely the NVPTX support should be migrated to the metadata & the previous flag implementation should be removed. Reviewers: aprantl Differential Revision: https://reviews.llvm.org/D50213 llvm-svn: 339939
* [codeview] Use push_macro to avoid conflicts instead of a prefixReid Kleckner2018-08-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: This prefix was added in r333421, and it changed our dumper output to say things like "CVRegEAX" instead of just "EAX". That's a functional change that I'd rather avoid. I tested GCC, Clang, and MSVC, and all of them support #pragma push_macro. They don't issue warnings whem the macro is not defined either. I don't have a Mac so I can't test the real termios.h header, but I looked at the termios.h sources online and looked for other conflicts. I saw only the CR* macros, so those are the ones we work around. Reviewers: zturner, JDevlieghere Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50851 llvm-svn: 339907
* [DWARF] Verifier now handles .debug_types sections.Paul Robinson2018-08-081-2/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D50466 llvm-svn: 339302
* [DebugInfo] Fine tune emitting flags as part of the producerJonas Devlieghere2018-08-081-3/+7
| | | | | | | | | When using APPLE extensions, don't duplicate the compiler invocation's flags both in AT_producer and AT_APPLE_flags. Differential revision: https://reviews.llvm.org/D50453 llvm-svn: 339268
* [DebugInfo] Reduce debug_str_offsets section sizePavel Labath2018-08-072-11/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The accelerator tables use the debug_str section to store their strings. However, they do not support the indirect method of access that is available for the debug_info section (DW_FORM_strx et al.). Currently our code is assuming that all strings can/will be referenced indirectly, and puts all of them into the debug_str_offsets section. This is generally true for regular (unsplit) dwarf, but in the DWO case, most of the strings in the debug_str section will only be used from the accelerator tables. Therefore the contents of the debug_str_offsets section will be largely unused and bloating the main executable. This patch rectifies this by teaching the DwarfStringPool to differentiate between strings accessed directly and indirectly. When a user inserts a string into the pool it has to declare whether that string will be referenced directly or not. If at least one user requsts indirect access, that string will be assigned an index ID and put into debug_str_offsets table. Otherwise, the offset table is skipped. This approach reduces the overall binary size (when compiled with -gdwarf-5 -gsplit-dwarf) in my tests by about 2% (debug_str_offsets is shrunk by 99%). Reviewers: probinson, dblaikie, JDevlieghere Subscribers: aprantl, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D49493 llvm-svn: 339122
* [DebugInfo/Verifier] Don't emit error for missing module in indexJonas Devlieghere2018-08-031-1/+2
| | | | | | | | | We don't expect module names to be present in the index. This patch adds DW_TAG_module to the blacklist. Differential revision: https://reviews.llvm.org/D50237 llvm-svn: 338878
* [MC] Report fatal error for DWARF types for non-ELF object filesJonas Devlieghere2018-08-012-4/+10
| | | | | | | | | | | | | | Getting the DWARF types section is only implemented for ELF object files. We already disabled emitting debug types in clang (r337717), but now we also report an fatal error (rather than crashing) when trying to obtain this section in MC. Additionally we ignore the generate debug types flag for unsupported target triples. See PR38190 for more information. Differential revision: https://reviews.llvm.org/D50057 llvm-svn: 338527
* [DWARF] Basic support for producing DWARFv5 .debug_addr sectionVictor Leschuk2018-08-011-0/+79
| | | | | | | | | | | | | | This revision implements support for generating DWARFv5 .debug_addr section. The implementation is pretty straight-forward: we just check the dwarf version and emit section header if needed. Reviewers: aprantl, dblaikie, probinson Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D50005 llvm-svn: 338487
* [DWARF v5] Reposting r337981, which was reverted in r337997 due to a test ↵Wolfgang Pieb2018-07-263-0/+150
| | | | | | | | | failure in debuginfo_tests. The test failure was caused by the compiler not emitting a __debug_ranges section with DWARF 4 and earlier when no ranges are needed. The test checks for the existence regardless. llvm-svn: 338081
* [DebugInfo] LowerDbgDeclare: Add derefs when handling CallInst usersVedant Kumar2018-07-264-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LowerDbgDeclare inserts a dbg.value before each use of an address described by a dbg.declare. When inserting a dbg.value before a CallInst use, however, it fails to append DW_OP_deref to the DIExpression. The DW_OP_deref is needed to reflect the fact that a dbg.value describes a source variable directly (as opposed to a dbg.declare, which relies on pointer indirection). This patch adds in the DW_OP_deref where needed. This results in the correct values being shown during a debug session for a program compiled with ASan and optimizations (see https://reviews.llvm.org/D49520). Note that ConvertDebugDeclareToDebugValue is already correct -- no changes there were needed. One complication is that SelectionDAG is unable to distinguish between direct and indirect frame-index (FRAMEIX) SDDbgValues. This patch also fixes this long-standing issue in order to not regress integration tests relying on the incorrect assumption that all frame-index SDDbgValues are indirect. This is a necessary fix: the newly-added DW_OP_derefs cannot be lowered properly otherwise. Basically the fix prevents a direct SDDbgValue with DIExpression(DW_OP_deref) from being dereferenced twice by a debugger. There were a handful of tests relying on this incorrect "FRAMEIX => indirect" assumption which actually had incorrect DW_AT_locations: these are all fixed up in this patch. Testing: - check-llvm, and an end-to-end test using lldb to debug an optimized program. - Existing unit tests for DIExpression::appendToStack fully cover the new DIExpression::append utility. - check-debuginfo (the debug info integration tests) Differential Revision: https://reviews.llvm.org/D49454 llvm-svn: 338069
* Revert r337981: it breaks the debuginfo-testsAlex Lorenz2018-07-263-150/+0
| | | | | | | This commit caused a regression in the debuginfo-tests: FAIL: debuginfo-tests :: apple-accel.cpp (40748 of 46595) llvm-svn: 337997
* [DWARF v5] Don't report an error when the .debug_rnglists section is empty ↵Wolfgang Pieb2018-07-261-1/+6
| | | | | | | | | | | or non-existent. Fixes PR38297. Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D49815 llvm-svn: 337993
* [DWARF v5] Don't emit multiple DW_AT_rnglists_base attributes. Some ↵Wolfgang Pieb2018-07-253-0/+150
| | | | | | | | | | | | refactoring of range lists emissions and added test cases. Reviewer: dblaikie Differential Revision: https://reviews.llvm.org/D49522 llvm-svn: 337981
* [DWARF v5] Refactor range lists dumping by using a more generic way of ↵Wolfgang Pieb2018-07-231-2/+2
| | | | | | | | | | | | | handling tables of lists. The intent is to use it for location list tables as well. Change is almost NFC with the exception of the spelling of some strings used during dumping (all lowercase now). Reviewer: JDevlieghere Differential Revision: https://reviews.llvm.org/D49500 llvm-svn: 337763
* [DebugInfo] Generate .debug_names section when it makes sensePavel Labath2018-07-203-10/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch makes us generate the debug_names section in response to some user-facing commands (previously it was only generated if explicitly selected via the -accel-tables option). My goal was to make this work for DWARF>=5 (as it's an official part of that standard), and also, as an extension, for DWARF<5 if one is explicitly tuning for lldb as a debugger (because it brings a large performance improvement there). This is slightly complicated by the fact that the debug_names tables are incompatible with the DWARF v4 type units (they assume that the type units are in the debug_info section), and unfortunately, right now we generate DWARF v4-style type units even for -gdwarf-5. For this reason, I disable all accelerator tables if the user requested type unit generation. I do this even for apple tables, as they have the same problem (in fact generating type units for apple targets makes us crash even before we get around to emitting the accelerator tables). Reviewers: JDevlieghere, aprantl, dblaikie, echristo, probinson Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49420 llvm-svn: 337544
* Rename __asan_gen_* symbols to ___asan_gen_*.Peter Collingbourne2018-07-182-4/+4
| | | | | | | | | | This prevents gold from printing a warning when trying to export these symbols via the asan dynamic list after ThinLTO promotes them from private symbols to external symbols with hidden visibility. Differential Revision: https://reviews.llvm.org/D49498 llvm-svn: 337428
* Fix some tests that had (implied) duplicate mtripleDavid Blaikie2018-07-182-6/+6
| | | | | | | I 'fixed' one of these to use %llc_dwarf unnecessarily, so switch them both back to using llc directly. llvm-svn: 337423
* [DebugInfo] Dwarfv5: Avoid unnecessary base_address specifiers in rnglistsDavid Blaikie2018-07-183-92/+85
| | | | | | | | | | | | Since DWARFv5 rnglists are self descriptive and have distinct encodings for base-relative (offset_pair) and absolute (start_length) entries, there's no need to use a base address specifier when describing a lone address range in a section. Use that, and improve the test coverage a bit here to include cases like this and others. llvm-svn: 337411
* [dwarfdump] Pretty print DW_AT_APPLE_runtime_classJonas Devlieghere2018-07-131-0/+1
| | | | | | | | | | | | Instead of printing DW_AT_APPLE_runtime_class (0x10) we now print DW_AT_APPLE_runtime_class (DW_LANG_ObjC) llvm-svn: 337011
* [DWARF v5] Generate range list tables into the .debug_rnglists section. No ↵Wolfgang Pieb2018-07-122-2/+106
| | | | | | | | | | | | support for split DWARF and no use of DW_FORM_rnglistx with the DW_AT_ranges attribute. Reviewer: aprantl Differential Revision: https://reviews.llvm.org/D49214 llvm-svn: 336927
* NFC - Various typo fixes in testsGabor Buella2018-07-041-2/+2
| | | | llvm-svn: 336268
OpenPOWER on IntegriCloud