summaryrefslogtreecommitdiffstats
path: root/llvm/lib/DebugInfo/DWARF
Commit message (Collapse)AuthorAgeFilesLines
...
* Change some StringRef::data() reinterpret_cast to bytes_begin() or ↵Fangrui Song2019-04-071-1/+1
| | | | | | arrayRefFromStringRef() llvm-svn: 357852
* [DWARF] Simplify DWARFDebugAranges::findAddressFangrui Song2019-04-061-15/+6
| | | | | | | | The current lower_bound approach has to check two iterators pos and pos-1. Changing it to upper_bound allows us to check one iterator (similar to DWARFUnitVector::getUnitFor*). llvm-svn: 357834
* [dwarfdump] Remove bogus verifier errorJonas Devlieghere2019-04-031-11/+1
| | | | | | | | The standard doesn't require a DW_TAG_variable, DW_TAG_formal_parameter or DW_TAG_constant to A DW_AT_type attribute describing the type of the variable. It only specifies that it *can* have one. llvm-svn: 357628
* [DWARF] check whether the DIE is valid before querying for informationPaul Semel2019-04-031-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D60147 llvm-svn: 357607
* [DWARF] Add D to Seen early to avoid duplicate elements in WorklistFangrui Song2019-03-271-7/+5
| | | | llvm-svn: 357054
* [DWARF] Simplify DWARFVerifier::handleDebugAbbrev. NFCFangrui Song2019-03-271-10/+3
| | | | llvm-svn: 357053
* Revert "[llvm] Reapply "Prevent duplicate files in debug line header in ↵Ali Tamur2019-03-261-17/+3
| | | | | | | | | | | | | dwarf 5."" This reverts commit rL357020. The commit broke the test llvm/test/tools/llvm-objdump/embedded-source.test on some builds including clang-ppc64be-linux-multistage, clang-s390x-linux, clang-with-lto-ubuntu, clang-x64-windows-msvc, llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast (and others). llvm-svn: 357026
* [llvm] Reapply "Prevent duplicate files in debug line header in dwarf 5."Ali Tamur2019-03-261-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reapply rL356941 after regenerating the object file in the failing test llvm/test/tools/llvm-objdump/embedded-source.test from source. Original commit message: [llvm] Prevent duplicate files in debug line header in dwarf 5. Motivation: In previous dwarf versions, file name indexes started from 1, and the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes the primary source file to be explicitly given an entry with an index number 0. The current implementation honors the specification by just duplicating the main source file, once with index number 0, and later maybe with another index number. While this is compliant with the letter of the standard, the duplication causes problems for consumers of this information such as lldb. (Some files are duplicated, where only some of them have a line table although all refer to the same file) With this change, dwarf 5 debug line section files always start from 0, and the zeroth entry is not duplicated whenever possible. This requires different handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5) However, I think the minor complication is worth it, because it enables all consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the file name list homogenously. Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D59515 llvm-svn: 357018
* Revert "[llvm] Prevent duplicate files in debug line header in dwarf 5."Ali Tamur2019-03-251-17/+3
| | | | | | | | This reverts commit 312ab05887d0e2caa29aaf843cefe39379a98d36. My commit broke the build; I will revert and find out what happened. llvm-svn: 356951
* [llvm] Prevent duplicate files in debug line header in dwarf 5.Ali Tamur2019-03-251-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Motivation: In previous dwarf versions, file name indexes started from 1, and the primary source file was not explicit. Dwarf 5 standard (6.2.4) prescribes the primary source file to be explicitly given an entry with an index number 0. The current implementation honors the specification by just duplicating the main source file, once with index number 0, and later maybe with another index number. While this is compliant with the letter of the standard, the duplication causes problems for consumers of this information such as lldb. (Some files are duplicated, where only some of them have a line table although all refer to the same file) With this change, dwarf 5 debug line section files always start from 0, and the zeroth entry is not duplicated whenever possible. This requires different handling of dwarf 4 and dwarf 5 during generation (e.g. when a function returns an index zero for a file name, it signals an error in dwarf 4, but not in dwarf 5) However, I think the minor complication is worth it, because it enables all consumers (lldb, gdb, dwarfdump, objdump, and so on) to treat all files in the file name list homogenously. Reviewers: dblaikie, probinson, aprantl, espindola Reviewed By: probinson Subscribers: emaste, jvesely, nhaehnle, aprantl, javed.absar, arichardson, hiraditya, MaskRay, rupprecht, jdoerfert, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D59515 llvm-svn: 356941
* [DWARF] Delete a stray break and a stray comment. NFCFangrui Song2019-03-231-2/+1
| | | | llvm-svn: 356838
* [DWARF] Refactor RelocVisitor and fix computation of SHT_RELA-typed ↵Fangrui Song2019-03-222-12/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | relocation entries Summary: getRelocatedValue may compute incorrect value for SHT_RELA-typed relocation entries. // DWARFDataExtractor.cpp uint64_t DWARFDataExtractor::getRelocatedValue(uint32_t Size, uint32_t *Off, ... // This formula is correct for REL, but may be incorrect for RELA if the value // stored in the location (getUnsigned(Off, Size)) is not zero. return getUnsigned(Off, Size) + Rel->Value; In this patch, we * refactor these visit* functions to include a new parameter `uint64_t A`. Since these visit* functions are no longer used as visitors, rename them to resolve*. + REL: A is used as the addend. A is the value stored in the location where the relocation applies: getUnsigned(Off, Size) + RELA: The addend encoded in RelocationRef is used, e.g. getELFAddend(R) * and add another set of supports* functions to check if a given relocation type is handled. DWARFObjInMemory uses them to fail early. Reviewers: echristo, dblaikie Reviewed By: echristo Subscribers: mgorny, aprantl, aheejin, fedor.sergeev, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57939 llvm-svn: 356729
* [DebugInfo] Introduce DW_OP_LLVM_convertMarkus Lavin2019-03-193-3/+6
| | | | | | | | | | | | | | | | | | | | | Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows for a convenient way to perform type conversions on the Dwarf expression stack. As an additional bonus it paves the way for using other Dwarf v5 ops that need to reference a base_type. The new DW_OP_LLVM_convert is used from lib/Transforms/Utils/Local.cpp to perform sext/zext on debug values but mainly the patch is about preparing terrain for adding other Dwarf v5 ops that need to reference a base_type. For Dwarf v5 the op maps to DW_OP_convert and for earlier versions a complex shift & mask pattern is generated to emulate sext/zext. This is a recommit of r356442 with trivial fixes for the failing tests. Differential Revision: https://reviews.llvm.org/D56587 llvm-svn: 356451
* Revert "[DebugInfo] Introduce DW_OP_LLVM_convert"Markus Lavin2019-03-193-6/+3
| | | | | | | | | | | | | This reverts commit 1cf4b593a7ebd666fc6775f3bd38196e8e65fafe. Build bots found failing tests not detected locally. Failing Tests (3): LLVM :: DebugInfo/Generic/convert-debugloc.ll LLVM :: DebugInfo/Generic/convert-inlined.ll LLVM :: DebugInfo/Generic/convert-linked.ll llvm-svn: 356444
* [DebugInfo] Introduce DW_OP_LLVM_convertMarkus Lavin2019-03-193-3/+6
| | | | | | | | | | | | | | | | | | | Introduce a DW_OP_LLVM_convert Dwarf expression pseudo op that allows for a convenient way to perform type conversions on the Dwarf expression stack. As an additional bonus it paves the way for using other Dwarf v5 ops that need to reference a base_type. The new DW_OP_LLVM_convert is used from lib/Transforms/Utils/Local.cpp to perform sext/zext on debug values but mainly the patch is about preparing terrain for adding other Dwarf v5 ops that need to reference a base_type. For Dwarf v5 the op maps to DW_OP_convert and for earlier versions a complex shift & mask pattern is generated to emulate sext/zext. Differential Revision: https://reviews.llvm.org/D56587 llvm-svn: 356442
* [llvm] Skip over empty line table entries.Mircea Trofin2019-03-151-9/+28
| | | | | | | | | | | | | | | | | | Summary: This is similar to how addr2line handles consecutive entries with the same address - pick the last one. Reviewers: dblaikie, friss, JDevlieghere Reviewed By: dblaikie Subscribers: eugenis, vitalybuka, echristo, JDevlieghere, probinson, aprantl, hiraditya, rupprecht, jdoerfert, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D58952 llvm-svn: 356265
* Revert "[llvm] Skip over empty line table entries."Evgeniy Stepanov2019-03-131-7/+0
| | | | | | | This reverts commit r355972. See the discussion at https://reviews.llvm.org/D58952. llvm-svn: 356001
* [llvm] Skip over empty line table entries.Mircea Trofin2019-03-121-0/+7
| | | | | | | | | | | | | | | | | | Summary: This is similar to how addr2line handles consecutive entries with the same address - pick the last one. Reviewers: dblaikie, friss, JDevlieghere Reviewed By: dblaikie Subscribers: ormris, echristo, JDevlieghere, probinson, aprantl, hiraditya, rupprecht, jdoerfert, llvm-commits Tags: #llvm, #debug-info Differential Revision: https://reviews.llvm.org/D58952 llvm-svn: 355972
* [DebugInfo] Fix the type of the formated variablePetar Jovanovic2019-03-071-2/+2
| | | | | | | | | | | | | Change the format type of *Personality and *LSDAAddress to PRIx64 since they are of type uint64_t. The problem was detected on mips builds, where it was printing junk values and causing test failure. Patch by Milos Stojanovic. Differential Revision: https://reviews.llvm.org/D58451 llvm-svn: 355607
* [DWARFFormValue] Don't consider DW_FORM_data4/8 to be section offsets.Jonas Devlieghere2019-03-051-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | When dumping ToT clan's debug info with dwarfdump, we were seeing an error saying that that the location list overflows the debug_loc section. After reducing the testcase we figured out that we were interpreting the DW_FORM_data4 as a section offset. In DWARF3 DW_FORM_data4 and DW_FORM_data8 served also as a section offset. Until now we didn't check check for the DWARF version, because some producers (read old versions of clang) were still emitting this. The relevant code/comment was added in 2013, and I believe it's now reasonable to start checking the version. The FormValue class is a little bit of a mess because it cashes the DWARF unit and context when it extracted the value itself. Several methods of the class rely on it being present, or return an Optional for the code path that needs it. At the same time the FormValue class also used in places where there's no DWARF unit. For this patch I went with the least invasive change: checking the version from the CU when it's available. If it's not (because the form value was created from a value directly) we default to the old behavior. Differential revision: https://reviews.llvm.org/D58698 llvm-svn: 355456
* Revert "[DWARFFormValue] Cleanup DWARFFormValue interface. (2/2) (NFC)"Vlad Tsyrklevich2019-03-024-22/+21
| | | | | | This reverts commit r355233, it was causing UBSan failures. llvm-svn: 355255
* [DWARFFormValue] Cleanup DWARFFormValue interface. (2/2) (NFC)Jonas Devlieghere2019-03-014-21/+22
| | | | | | | Continues the work started in r354941. Changes (all but one) uses of the extractValue to static createFromData. llvm-svn: 355233
* dsymutil support for DW_OP_convertAdrian Prantl2019-02-281-3/+37
| | | | | | | | | | | Add support for cloning DWARF expressions that contain base type DIE references in dsymutil. <rdar://problem/48167812> Differential Revision: https://reviews.llvm.org/D58534 llvm-svn: 355148
* [DebugInfo] add SectionedAddress to DebugInfo interfaces.Alexey Lapshin2019-02-279-70/+122
| | | | | | | | | | | | | | | | | That patch is the fix for https://bugs.llvm.org/show_bug.cgi?id=40703 "wrong line number info for obj file compiled with -ffunction-sections" bug. The problem happened with only .o files. If object file contains several .text sections then line number information showed incorrectly. The reason for this is that DwarfLineTable could not detect section which corresponds to specified address(because address is the local to the section). And as the result it could not select proper sequence in the line table. The fix is to pass SectionIndex with the address. So that it would be possible to differentiate addresses from various sections. With this fix llvm-objdump shows correct line numbers for disassembled code. Differential review: https://reviews.llvm.org/D58194 llvm-svn: 354972
* [DWARFFormValue] Cleanup DWARFFormValue interface. (NFC)Jonas Devlieghere2019-02-274-34/+55
| | | | | | | | | | DWARFFormValues can be created from a data extractor or by passing its value directly. Until now this was done by member functions that modified an existing object's internal state. This patch replaces a subset of these methods with static method that return a new DWARFFormValue. llvm-svn: 354941
* [DebugInfo] Prep llvm-dwarfdump for typed DW5 ops.Markus Lavin2019-02-215-13/+60
| | | | | | | | | | | Adds llvm-dwarfdump support for pretty printing Dwarf5 expressions ops that reference a base type (right now only DW_OP_convert is added). Includes verification to verify that the ops operand is actually a DW_TAG_base_type DIE. Differential Revision: https://reviews.llvm.org/D58442 llvm-svn: 354552
* [DebugInfo]Print correct value for special opcode address incrementJames Henderson2019-02-061-2/+2
| | | | | | | | | | | The wrong variable was being used when printing the address increment in verbose output of .debug_line. This patch fixes this. Reviewed by: JDevlieghere Differential Revision: https://reviews.llvm.org/D57693 llvm-svn: 353288
* [DWARF v5] Fix DWARF emitter and consumer to produce/expect a uleb for a ↵Wolfgang Pieb2019-02-011-1/+2
| | | | | | | | | | location description's length. Reviewer: davide, JDevliegere Differential Revision: https://reviews.llvm.org/D57550 llvm-svn: 352889
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1928-112/+84
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* llvm-dwarfdump: Skip address index info (and dump only the address, if ↵David Blaikie2018-12-241-4/+5
| | | | | | | | found) when non-verbose dumping addrx forms There's a few bugs here still - demonstrated with FIXITs in the test. llvm-svn: 350046
* DebugInfo: Accurately propagate the section used by a relocation when ↵David Blaikie2018-12-221-4/+4
| | | | | | | | | | | | | | | | | accessing ranges defined by low/high_pc This is difficult/not possible to test in LLVM, but is visible as a crash in LLD when parsing DWARF to generate gdb-index. This function is called by llvm-dwarfdump when parsing high_pc for non-verbose output (to print the actual high_pc rather than the low_pc relative value), but in that case llvm-dwarfdump doesn't print section names (if it did, it would hit this problem). We could add some other features to llvm-dwarfdump to expose this, but nothing really springs to my mind. I will add a test to lld, though. llvm-svn: 350010
* llvm-dwarfdump: Dump the section name/number for addr attributesDavid Blaikie2018-12-221-1/+1
| | | | llvm-svn: 350009
* llvm-dwarfdump: Remove extraneous space between '(' and 'indexed'David Blaikie2018-12-221-2/+2
| | | | | | When dumping string or address indexes llvm-svn: 349997
* llvm-dwarfdump: Print the section name/number for addr_index attributesDavid Blaikie2018-12-221-3/+12
| | | | | | (addr attributes coming shortly) llvm-svn: 349996
* DebugInfo: Refactor named section dumping into a reusable helperDavid Blaikie2018-12-222-9/+16
| | | | | | | | | | | Currently the section name (& possibly number) is only printed on addresses in ranges - but no reason it couldn't also be displayed on other addresses (like low/high PC). Refactor in that direction by pulling out the section lookup and name ambiguity dumping logic into a reusable helper. llvm-svn: 349995
* DebugInfo: Remove extra attribute lookupDavid Blaikie2018-12-221-3/+2
| | | | llvm-svn: 349985
* libDebugInfo: Refactor error handling in range list parsingDavid Blaikie2018-12-222-15/+15
| | | | | | | | Propagate the llvm::Error a little further up. This is NFC for llvm-dwarfdump in this change, but allows ld.lld to emit more precise error messages about which object and archive the erroneous DWARF is in. llvm-svn: 349978
* Reapply: DebugInfo: Assume an absence of ranges or high_pc on a CU means the ↵David Blaikie2018-12-211-21/+0
| | | | | | | | | | | | | | | | | | | | | CU is empty (devoid of code addresses) Originally committed in r349333, reverted in r349353. GCC emitted these unconditionally on/before 4.4/March 2012 Clang emitted these unconditionally on/before 3.5/March 2014 This improves performance when parsing CUs (especially those using split DWARF) that contain no code ranges (such as the mini CUs that may be created by ThinLTO importing - though generally they should be/are avoided, especially for Split DWARF because it produces a lot of very small CUs, which don't scale well in a bunch of other ways too (including size)). The revert was due to a (Google internal) test that had some checked in old object files missing DW_AT_ranges. That's since been fixed. llvm-svn: 349968
* [Dwarf/AArch64] Return address signing B key dwarf supportLuke Cheeseman2018-12-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | - When signing return addresses with -msign-return-address=<scope>{+<key>}, either the A key instructions or the B key instructions can be used. To correctly authenticate the return address, the unwinder/debugger must know which key was used to sign the return address. - When and exception is thrown or a break point reached, it may be necessary to unwind the stack. To accomplish this, the unwinder/debugger must be able to first authenticate an the return address if it has been signed. - To enable this, the augmentation string of CIEs has been extended to allow inclusion of a 'B' character. Functions that are signed using the B key variant of the instructions should have and FDE whose associated CIE has a 'B' in the augmentation string. - One must also be able to preserve these semantics when first stepping from a high level language into assembly and then, as a second step, into an object file. To achieve this, I have introduced a new assembly directive '.cfi_b_key_frame ', that tells the assembler the current frame uses return address signing with the B key. - This ensures that the FDE is associated with a CIE that has 'B' in the augmentation string. Differential Revision: https://reviews.llvm.org/D51798 llvm-svn: 349895
* llvm-dwarfdump: Improve/fix pretty printing of array dimensionsDavid Blaikie2018-12-191-18/+47
| | | | | | | | | | | | | | This is to address post-commit feedback from Paul Robinson on r348954. The original commit misinterprets count and upper bound as the same thing (I thought I saw GCC producing an upper bound the same as Clang's count, but GCC correctly produces an upper bound that's one less than the count (in C, that is, where arrays are zero indexed)). I want to preserve the C-like output for the common case, so in the absence of a lower bound the count (or one greater than the upper bound) is rendered between []. In the trickier cases, where a lower bound is specified, a half-open range is used (eg: lower bound 1, count 2 would be "[1, 3)" and an unknown parts use a '?' (eg: "[1, ?)" or "[?, 7)" or "[?, ? + 3)"). Reviewers: aprantl, probinson, JDevlieghere Differential Revision: https://reviews.llvm.org/D55721 llvm-svn: 349670
* [AArch64] - Return address signing dwarf supportLuke Cheeseman2018-12-182-8/+9
| | | | | | | | | | | | | | - Reapply changes intially introduced in r343089 - The archtecture info is no longer loaded whenever a DWARFContext is created - The runtimes libraries (santiziers) make use of the dwarf context classes but do not intialise the target info - The architecture of the object can be obtained without loading the target info - Adding a method to the dwarf context to get this information and multiplex the string printing later on Differential Revision: https://reviews.llvm.org/D55774 llvm-svn: 349472
* Revert "DebugInfo: Assume an absence of ranges or high_pc on a CU means the ↵Eric Liu2018-12-171-0/+21
| | | | | | | | | CU is empty (devoid of code addresses)" This reverts commit r349333. It caused internal test to fail. I have sent more information to the author. llvm-svn: 349353
* DebugInfo: Assume an absence of ranges or high_pc on a CU means the CU is ↵David Blaikie2018-12-171-21/+0
| | | | | | | | | | | | | | | | empty (devoid of code addresses) GCC emitted these unconditionally on/before 4.4/March 2012 Clang emitted these unconditionally on/before 3.5/March 2014 This improves performance when parsing CUs (especially those using split DWARF) that contain no code ranges (such as the mini CUs that may be created by ThinLTO importing - though generally they should be/are avoided, especially for Split DWARF because it produces a lot of very small CUs, which don't scale well in a bunch of other ways too (including size)). llvm-svn: 349333
* DebugInfo/DWARF: Pretty print subroutine typesDavid Blaikie2018-12-121-2/+19
| | | | | | | | Doesn't handle varargs and other fun things, but it's a start. (also doesn't print these strictly as valid C++ when it's a pointer to function, it'll print as "void(int)*" instead of "void (*)(int)") llvm-svn: 348965
* DebugInfo/DWARF: Improve dumping of pointers to members ('int foo::*' rather ↵David Blaikie2018-12-121-0/+5
| | | | | | than 'int*') llvm-svn: 348962
* DebugInfo/DWARF: Refactor type dumping to dump types, rather than DIEs that ↵David Blaikie2018-12-121-5/+3
| | | | | | | | | | | | reference types This lays the foundation for dumping types not referenced by DW_AT_type attributes (in the near-term, that'll be DW_AT_containing_type for a DW_TAG_ptr_to_member_type - in the future, potentially dumping the pretty printed name next to the DW_TAG for the type, rather than only when the type is referenced from elsewhere) llvm-svn: 348961
* DebugInfo/DWARF: Refactor getAttributeValueAsReferencedDie to accept a ↵David Blaikie2018-12-121-3/+11
| | | | | | | | | DWARFFormValue Save searching for the attribute again when you already have the DWARFFormValue at hand. llvm-svn: 348960
* llvm-dwarfdump: Dump array dimensions in stringified type namesDavid Blaikie2018-12-121-2/+21
| | | | llvm-svn: 348954
* [llvm-dwarfdump] - Dump the older versions of .eh_frame/.debug_frame correctly.George Rimar2018-12-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | The issue is the following. DWARF 2 used version 1 for .debug_frame. (Appendix G, p. 416 http://dwarfstd.org/doc/DWARF5.pdf) lib/MC now always sets version 1 for .eh_frame (and sets 1-4 versions for .debug_frame correctly): https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCDwarf.cpp#L1530 https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCDwarf.cpp#L1562 https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCDwarf.cpp#L1602 In version 1, return_address_register was defined as ubyte, while other versions switched to uleb128. (p 62, http://www.dwarfstd.org/doc/dwarf-2.0.0.pdf) Patch teaches llvm-dwarfdump about this difference. Differential revision: https://reviews.llvm.org/D54860 llvm-svn: 348242
* [llvm-dwarfdump] - Stop printing the bogus empty section name on invalid dwarf.George Rimar2018-12-031-2/+2
| | | | | | | | | | | | | | | | | | | | | When there is no .debug_addr section for some reason, llvm-dwarfdump would print the bogus empty section name when dumping ranges in .debug_info: DW_AT_ranges [DW_FORM_rnglistx] (indexed (0x0) rangelist = 0x00000004 [0x0000000000000000, 0x0000000000000001) "" [0x0000000000000000, 0x0000000000000002) "") That happens because of the code which uses 0 (zero) as a section index as a default value. The code should use -1ULL instead because technically 0 is a valid zero section index in ELF and -1ULL is a special constant used that means "no section available". This is mostly a fix for the overall correctness/safety of the code, but a test case is provided too. Differential revision: https://reviews.llvm.org/D55113 llvm-svn: 348115
OpenPOWER on IntegriCloud