summaryrefslogtreecommitdiffstats
path: root/llvm/lib/MC
Commit message (Collapse)AuthorAgeFilesLines
* [APFloat] Fix checked error assert failuresEhud Katz2020-01-091-1/+3
| | | | | | | | | | | `APFLoat::convertFromString` returns `Expected` result, which must be "checked" if the LLVM_ENABLE_ABI_BREAKING_CHECKS preprocessor flag is set. To mark an `Expected` result as "checked" we must consume the `Error` within. In many cases, we are only interested in knowing if an error occured, without the need to examine the error info. This is achieved, easily, with the `errorToBool()` API.
* [BranchAlign] Compiler support for suppressing branch alignPhilip Reames2020-01-082-1/+6
| | | | | | | | | | | | As discussed heavily in the original review (D70157), there's a need for the compiler to be able to selective suppress padding (either nop or prefix) to respect assumptions about the meaning of labels and instructions in generated code. Rather than wait for syntax to be finalized - which appears to be a very slow process - this patch focuses on the compiler use case and *only* worries about the integrated assembler. To my knowledge, this covers all cases mentioned to date for clang/JIT support. For testing purposes, I wired it up so that if the integrated assembler was using autopadding for branch alignment (e.g. enabled at command line) then the textual assembly output would contain a comment for each location where padding was enabled or disabled. This seemed like the least painful choice overall. Note that the result of this patch effective disables the jcc errata mitigation for many constructs (statepoints, implicit null checks, xray, etc...) which is non ideal. It is at least *correct* and should allow us to enable the mitigation for the compiler. Once that's done, and a few other items are worked through, we probably want to come back to this an explore a bundling based approach instead so that we can pad instructions while keeping labels in the right place. Differential Revision: https://reviews.llvm.org/D72303
* [MC] writeFragment - assert MCFragment::FT_Fill length is legal.Simon Pilgrim2020-01-081-0/+1
| | | | Silence (clang/MSVC) static analyzer warnings that the fragment data may either write out of bounds of the local array or reference uninitialized data.
* [NFC] Use isX86() instead of getArch()Jim Lin2020-01-071-3/+2
| | | | | | | | | | | | | | Summary: This is a clean up for https://reviews.llvm.org/D72247. Reviewers: MaskRay, craig.topper, jhenderson Reviewed By: MaskRay Subscribers: hiraditya, rupprecht, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D72320
* [MC] Add parameter `Address` to MCInstPrinter::printInstFangrui Song2020-01-063-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | printInst prints a branch/call instruction as `b offset` (there are many variants on various targets) instead of `b address`. It is a convention to use address instead of offset in most external symbolizers/disassemblers. This difference makes `llvm-objdump -d` output unsatisfactory. Add `uint64_t Address` to printInst(), so that it can pass the argument to printInstruction(). `raw_ostream &OS` is moved to the last to be consistent with other print* methods. The next step is to pass `Address` to printInstruction() (generated by tablegen from the instruction set description). We can gradually migrate targets to print addresses instead of offsets. In any case, downstream projects which don't know `Address` can pass 0 as the argument. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72172
* [NFC] Fix trivial typos in commentsJames Henderson2020-01-063-5/+5
| | | | | | | | Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72143 Patch by Kazuaki Ishizaki.
* [APFloat] Add recoverable string parsing errors to APFloatEhud Katz2020-01-061-2/+1
| | | | | | Implementing the APFloat part in PR4745. Differential Revision: https://reviews.llvm.org/D69770
* [MC] Reorder MCFragment members to decrease paddingFangrui Song2020-01-051-2/+2
| | | | | | | sizeof(MCFragment) does not change, but some if its subclasses do, e.g. on a 64-bit platform, sizeof(MCEncodedFragment) decreases from 64 to 56, sizeof(MCDataFragment) decreases from 224 to 216.
* [MC] Delete MCFragment::isDummy. NFCFangrui Song2020-01-051-1/+1
| | | | | isa<...>, dyn_cast<...> and cast<...> are used by other fragments. Don't make MCDummyFragment special.
* [MC][ARM] Delete MCSection::HasData and move SHF_ARM_PURECODE logic to ↵Fangrui Song2020-01-052-8/+1
| | | | | | | | ARMELFObjectWriter::addTargetSectionFlags This simplifies the generic interface and also makes SHF_ARM_PURECODE more robust (fixes a TODO). Inspecting MCDataFragment contents covers more cases than MCObjectStreamer::EmitBytes.
* [MC] Delete MCSection::{rbegin,rend}Fangrui Song2020-01-051-2/+2
|
* [MC] Drop an unused rule about absolute temporary symbolsFangrui Song2020-01-051-4/+0
|
* [NFC] Fixes -Wrange-loop-analysis warningsMark de Wever2020-01-011-1/+1
| | | | | | This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71857
* [MC][TargetMachine] Delete MCTargetOptions::MCPIECopyRelocationsFangrui Song2020-01-011-2/+2
| | | | | | | | | | | | clang/lib/CodeGen/CodeGenModule performs the -mpie-copy-relocations check and sets dso_local on applicable global variables. We don't need to duplicate the work in TargetMachine shouldAssumeDSOLocal. Verified that -mpie-copy-relocations can still emit PC relative relocations for external variable accesses. clang -target x86_64 -fpie -mpie-copy-relocations -c => R_X86_64_PC32 clang -target aarch64 -fpie -mpie-copy-relocations -c => R_AARCH64_ADR_PREL_PG_HI21+R_AARCH64_LDST64_ABS_LO12_NC
* [X86][AsmParser] re-introduce 'offset' operatorEric Astor2019-12-301-10/+42
| | | | | | | | | | | | | | | | | | | | | | | Summary: Amend MS offset operator implementation, to more closely fit with its MS counterpart: 1. InlineAsm: evaluate non-local source entities to their (address) location 2. Provide a mean with which one may acquire the address of an assembly label via MS syntax, rather than yielding a memory reference (i.e. "offset asm_label" and "$asm_label" should be synonymous 3. address PR32530 Based on http://llvm.org/D37461 Fix broken test where the break appears unrelated. - Set up appropriate memory-input rewrites for variable references. - Intel-dialect assembly printing now correctly handles addresses by adding "offset". - Pass offsets as immediate operands (using "r" constraint for offsets of locals). Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D71436
* Revert "[COFF] Make the autogenerated .weak.<name>.default symbols static"Martin Storsjö2019-12-281-13/+9
| | | | | | | This reverts commit 7ca86ee6494d4307333b300bae80e42df4a5140f. Apparently this change causes MS link.exe to error out with "LNK1235: corrupt or invalid COFF symbol table".
* [COFF] Make the autogenerated .weak.<name>.default symbols staticMartin Storsjö2019-12-281-9/+13
| | | | | | | | | | | | | | If we have references to the same extern_weak in multiple objects, all of them would generate external symbols with the same name. Make them static to avoid duplicate definitions; nothing should need to refer to this symbol outside of the current object. GCC/binutils seems to handle the same by not using a fixed string for the ".default" suffix, but instead using the name of some other defined external symbol from the same object (which is supposed to be unique among objects unless there's other duplicate definitions). Differential Revision: https://reviews.llvm.org/D71711
* [NFC] Style cleanupsShengchen Kan2019-12-231-11/+11
| | | | | | 1. Remove duplicate function for class name at the beginning of the comment. 2. Use auto where the type is already obvious from the context.
* [ms] [X86] Use "P" modifier on operands to call instructions in inline X86 ↵Eric Astor2019-12-221-1/+7
| | | | | | | | | | | | | | | | | | | | assembly. Summary: This is documented as the appropriate template modifier for call operands. Fixes PR44272, and adds a regression test. Also adds support for operand modifiers in Intel-style inline assembly. Reviewers: rnk Reviewed By: rnk Subscribers: merge_guards_bot, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D71677
* Align branches within 32-Byte boundary (NOP padding)Philip Reames2019-12-203-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WARNING: If you're looking at this patch because you're looking for a full performace mitigation of the Intel JCC Erratum, this is not it! This is a preliminary patch on the patch towards mitigating the performance regressions caused by Intel's microcode update for Jump Conditional Code Erratum. For context, see: https://www.intel.com/content/www/us/en/support/articles/000055650.html The patch adds the required assembler infrastructure and command line options needed to exercise the logic for INTERNAL TESTING. These are NOT public flags, and should not be used for anything other than LLVM's own testing/debugging purposes. They are likely to change both in spelling and meaning. WARNING: This patch is knowingly incorrect in some cornercases. We need, and do not yet provide, a mechanism to selective enable/disable the padding. Conversation on this will continue in parellel with work on extending this infrastructure to support prefix padding. The goal here is to have the assembler align specific instructions such that they neither cross or end at a 32 byte boundary. The impacted instructions are: a. Conditional jump. b. Fused conditional jump. c. Unconditional jump. d. Indirect jump. e. Ret. f. Call. The new options for llvm-mc are: -x86-align-branch-boundary=NUM aligns branches within NUM byte boundary. -x86-align-branch=TYPE[+TYPE...] specifies types of branches to align. A new MCFragment type, MCBoundaryAlignFragment, is added, which may emit NOP to align the fused/unfused branch. alignBranchesBegin inserts MCBoundaryAlignFragment before instructions, alignBranchesEnd marks the end of the branch to be aligned, relaxBoundaryAlign grows or shrinks sizes of NOP to align the target branch. Nop padding is disabled when the instruction may be rewritten by the linker, such as TLS Call. Process Note: I am landing a patch by skan as it has been LGTMed, and continuing to iterate on the review is simply slowing us down at this point. We can and will continue to iterate in tree. Patch By: skan Differential Revision: https://reviews.llvm.org/D70157
* [XCOFF][AIX] Fix for missing of undefined symbols from symbol tablejasonliu2019-12-191-7/+7
| | | | | | | | | Summary: When we use undefined symbol with its qualname, we are not able to generate that symbol because of the logic of early "continue" that skip the qualname symbol. This patch fixes it. Differential revision: https://reviews.llvm.org/D71667
* [ MC ] Match labels to existing fragments even when switching sections.Michael Trent2019-12-182-14/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (This commit restores the original branch (4272372c571) and applies an additional change dropped from the original in a bad merge. This change should address the previous bot failures. Both changes reviewed by pete.) Summary: This commit builds upon Derek Schuff's 2014 commit for attaching labels to existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 ) When temporary labels appear ahead of a fragment, MCObjectStreamer will track the temporary label symbol in a "Pending Labels" list. Labels are associated with fragments when a real fragment arrives; otherwise, an empty data fragment will be created if the streamer's section changes or if the stream finishes. This commit moves the "Pending Labels" list into each MCStream, so that this label-fragment matching process is resilient to section changes. If the streamer emits a label in a new section, switches to another section to do other work, then switches back to the first section and emits a fragment, that initial label will be associated with this new fragment. Labels will only receive empty data fragments in the case where no other fragment exists for that section. The downstream effects of this can be seen in Mach-O relocations. The previous approach could produce local section relocations and external symbol relocations for the same data in an object file, and this mix of relocation types resulted in problems in the ld64 Mach-O linker. This commit ensures relocations triggered by temporary labels are consistent. Reviewers: pete, ab, dschuff Reviewed By: pete, dschuff Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71368
* Revert "[ MC ] Match labels to existing fragments even when switching sections."Mitch Phillips2019-12-172-94/+13
| | | | | | | This reverts commit 4272372c571cd33edc77a8844b0a224ad7339138. Caused an MSan buildbot failure. More information available in the patch that introduced the bug: https://reviews.llvm.org/D71368
* Recommit "[DebugInfo] Refactored macro related generation,Sourabh Singh Tomar2019-12-181-0/+5
| | | | | | | | | | | | | | | | | | added a test case for macinfo.dwo emission." This was reverted in caa412090666c10f854322cdc701c1cbf8ed726e, since it was causing an assertion failure on Windows bots. This revision is revised to fix that. Original commit message - [DebugInfo] Refactored macro related generation, added a test case for macinfo.dwo emission. Reviewers: dblaikie, aprantl, jini.susan.george Tags: #debug-info #llvm Differential Revision: https://reviews.llvm.org/D71008
* [ MC ] Match labels to existing fragments even when switching sections.Michael Trent2019-12-172-13/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit builds upon Derek Schuff's 2014 commit for attaching labels to existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 ) When temporary labels appear ahead of a fragment, MCObjectStreamer will track the temporary label symbol in a "Pending Labels" list. Labels are associated with fragments when a real fragment arrives; otherwise, an empty data fragment will be created if the streamer's section changes or if the stream finishes. This commit moves the "Pending Labels" list into each MCStream, so that this label-fragment matching process is resilient to section changes. If the streamer emits a label in a new section, switches to another section to do other work, then switches back to the first section and emits a fragment, that initial label will be associated with this new fragment. Labels will only receive empty data fragments in the case where no other fragment exists for that section. The downstream effects of this can be seen in Mach-O relocations. The previous approach could produce local section relocations and external symbol relocations for the same data in an object file, and this mix of relocation types resulted in problems in the ld64 Mach-O linker. This commit ensures relocations triggered by temporary labels are consistent. Reviewers: pete, ab, dschuff Reviewed By: pete, dschuff Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71368
* [MC] Delete redundant alignment update from MCELFStreamer::EmitCommonSymbol. NFCFangrui Song2019-12-161-4/+0
| | | | EmitValueToAlignment() updates the maximum alignment.
* [MC] Delete STT_SECTION special cases from MCSymbolELF::setType and setBindingFangrui Song2019-12-151-4/+0
| | | | | The special cases added by rL293936 were no longer needed after rL296180 disallowed redefinition of section symbols.
* [MC] Assume CommentStream is non-null in MCDisassembler::tryAdding*Fangrui Song2019-12-151-5/+3
| | | | | AArch64/ARM/X86 call the two functions. CommentStream is always initialized.
* [MC] Ignore VK_WEAKREF in MCValue::getAccessVariantFangrui Song2019-12-151-4/+1
| | | | MCSymbolRefExpr::getVariantKindForName does not return VK_WEAKREF, so this code path is not exercised. Moreoever, .weakref is probably a feature that nobody uses.
* [MC] Delete unused MCAsmInfoELF::UsesNonexecutableStackSection after ↵Fangrui Song2019-12-151-2/+0
| | | | | | EM_WEBASSEMBLY was removed in D48744 This removes remnant of D15969 which hasn't been removed by D48744.
* [WebAssembly] Add new `export_name` clang attribute for controlling wasm ↵Sam Clegg2019-12-111-0/+10
| | | | | | | | | | | | | | | | | | | | export names This is equivalent to the existing `import_name` and `import_module` attributes which control the import names in the final wasm binary produced by lld. This maps the existing This attribute currently requires a string rather than using the symbol name for a couple of reasons: 1. Avoid confusion with static and dynamic linking which is based on symbol name. Exporting a function from a wasm module using this directive is orthogonal to both static and dynamic linking. 2. Avoids name mangling. Differential Revision: https://reviews.llvm.org/D70520
* [BUG-FIX][XCOFF] fixed a bug of XCOFFObjectFile.cpp when there is padding at ↵diggerlin2019-12-101-2/+4
| | | | | | | | | | | | the last csect of a sections SUMMARY: Fixed a bug of XCOFFObjectFile.cpp when there is padding at the last csect of a sections. when there is a tail padding of a section, but the value of CurrentAddressLocation do not be increased by the padding size. it will hit assert assert(CurrentAddressLocation == Section->Address && "We should have no padding between sections."); Reviewers: daltenty,hubert.reinterpretcast, Differential Revision: https://reviews.llvm.org/D70859
* [MC] Delete MCCodePadderFangrui Song2019-12-096-471/+1
| | | | | | | | | | | | | | | | | | | | | D34393 added MCCodePadder as an infrastructure for padding code with NOP instructions. It lacked tests and was not being worked on since then. Intel has now worked on an assembler patch to mitigate performance loss after applying microcode update for the Jump Conditional Code Erratum. https://www.intel.com/content/www/us/en/support/articles/000055650/processors.html This new patch shares similarity with MCCodePadder, but has a concrete use case in mind and is being actively developed. The infrastructure it introduces can potentially be used for general performance improvement via alignment. Delete the unused MCCodePadder so that people can develop the new feature from a clean state. Reviewed By: jyknight, skan Differential Revision: https://reviews.llvm.org/D71106
* [WebAssebmly][MC] Support .import_name/.import_field asm directivesSam Clegg2019-12-061-1/+1
| | | | | | | | Convert the MC test to use asm rather than bitcode. This is a precursor to https://reviews.llvm.org/D70520. Differential Revision: https://reviews.llvm.org/D70877
* [MC] Rewrite tablegen for printInstrAlias to comiple faster, NFCReid Kleckner2019-12-061-0/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, the *InstPrinter.cpp files of each target where some of the slowest objects to compile in all of LLVM. See this snippet produced by ClangBuildAnalyzer: https://reviews.llvm.org/P8171$96 Search for "InstPrinter", and see that it shows up in a few places. Tablegen was emitting a large switch containing a sequence of operand checks, each of which created many conditions and many BBs. Register allocation and jump threading both did not scale well with such a large repetitive sequence of basic blocks. So, this change essentially turns those control flow structures into data. The previous structure looked like: switch (Opc) { case TGT::ADD: // check alias 1 if (MI->getOperandCount() == N && // check num opnds MI->getOperand(0).isReg() && // check opnd 0 ... MI->getOperand(1).isImm() && // check opnd 1 AsmString = "foo"; break; } // check alias 2 if (...) ... return false; The new structure looks like: OpToPatterns: Sorted table of opcodes mapping to pattern indices. \-> Patterns: List of patterns. Previous table points to subrange of patterns to match. \-> Conds: The if conditions above encoded as a kind and 32-bit value. See MCInstPrinter.cpp for the details of how the new data structures are interpreted. Here are some before and after metrics. Time to compile AArch64InstPrinter.cpp: 0m29.062s vs. 0m2.203s size of the obj: 3.9M vs. 676K size of clang.exe: 97M vs. 96M I have not benchmarked disassembly performance, but typically disassemblers are bottlenecked on IO and string processing, not alias matching, so I'm not sure it's interesting enough to be worth doing. Reviewers: RKSimon, andreadb, xbolva00, craig.topper Reviewed By: craig.topper Differential Revision: https://reviews.llvm.org/D70650
* [NFC][AIX][XCOFF] if the size of Csect is zero, the Csect do not need write ↵diggerlin2019-12-061-1/+2
| | | | | | | | | | | | | | | any data into sections SUMMARY: if the size of Csect is zero, the Csect do not need write any data into sections for example, the TOC Csect has zero size, it do not need invoke a Asm.writeSectionData(W.OS, Csect.MCCsect, Layout); Reviewers: daltenty Subscribers: rupprecht, seiyai,hiraditya Differential Revision: https://reviews.llvm.org/D71120
* [NFC][AIX][XCOFF] fixed compile warning on the strncpy.diggerlin2019-12-061-1/+1
| | | | | | | | | | | | SUMMARY: There is warning when compile the file XCOFFObjectWriter.cpp /srv/llvm-buildbot-srcatch/llvm-build-dir/openmp-gcc-x86_64-linux-debian/llvm.src/llvm/lib/MC/XCOFFObjectWriter.cpp:414:17: warning: 'char* strncpy(char*, const char*, size_t)' specified bound 8 equals destination size [-Wstringop-truncation] The patch fixed the warning. Reviewer: daltenty Differential Revision: https://reviews.llvm.org/D71119
* [XCOFF][AIX] Emit TOC entries for object file generationjasonliu2019-12-042-6/+6
| | | | | | | | | | | | | | | | | | | | Summary: Implement emitTCEntry for PPCTargetXCOFFStreamer. Add TC csects to TOCCsects for object file writing. Note: 1. I did not include any raw data testing for this object file generation because TC entries raw data will all be 0 without relocation implemented. I will add raw data testing as part of relocation testing later. 2. I removed "Symbol->setFragment(F);" for common symbols because we don't need it, and if we have it then we would hit assertions below: Assertion `(SymbolContents == SymContentsUnset || SymbolContents == SymContentsOffset) && "Cannot get offset for a common/variable symbol"' failed. 3.Fixed incorrect TOC-base alignment. Differential Revision: https://reviews.llvm.org/D70798
* [DebugInfo] Support for debug_macinfo.dwo section in llvm and llvm-dwarfdump.Sourabh Singh Tomar2019-12-031-0/+2
| | | | | | | | | | | This patch adds support for debug_macinfo.dwo section[pre-standardized] to llvm and llvm-dwarfdump. Reviewers: probinson, dblaikie, aprantl, jini.susan.george, alok Differential Revision: https://reviews.llvm.org/D70705 Tags: #debug-info #llvm
* [AIX] Emit TOC entries for ASM printingDavid Tenty2019-11-271-0/+2
| | | | | | | | | | | | | | | | | | | | Summary: Emit the correct .toc psuedo op when we change to the TOC and emit TC entries. Make sure TOC psuedos get the right symbols via overriding getMCSymbolForTOCPseudoMO on AIX. Add a test for TOC assembly writing and update tests to include TOC entries. Also make sure external globals have a csect set and handle external function descriptor (originally authored by Jason Liu) so we can emit TOC entries for them. Reviewers: DiggerLin, sfertile, Xiangling_L, jasonliu, hubert.reinterpretcast Reviewed By: jasonliu Subscribers: arphaman, wuzish, nemanjai, hiraditya, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70461
* [MC] Produce proper section relative relocations for COFF in .debug_frameMartin Storsjö2019-11-271-1/+2
| | | | | | | | | | | | | The third parameter to Streamer.EmitSymbolValue() is "bool IsSectionRelative = false". For ELF, these debug sections are mapped to address zero, so a normal, absolute address relocation works just fine, but COFF needs a section relative relocation, and COFF is the only target where needsDwarfSectionOffsetDirective() returns true. This matches how EmitSymbolValue is called elsewhere in the same source file. Differential Revision: https://reviews.llvm.org/D70661
* [XCOFF][AIX] Check linkage on the function, and two fixes for commentsjasonliu2019-11-261-1/+1
| | | | | | This is a follow up commit to address post-commit comment in D70443 Differential revision: https://reviews.llvm.org/D70443
* [AIX][XCOFF] Generate undefined symbol in symbol table for external function ↵jasonliu2019-11-251-7/+33
| | | | | | | | | | | | | | | | call Summary: This patch sets up the infrastructure for 1. Associate MCSymbolXCOFF with an MCSectionXCOFF when it could not get implicitly associated. 2. Generate undefined symbols. The patch itself generates undefined symbol for external function call only. Generate undefined symbol for external global variable and external function descriptors will be handled in separate patch(s) after this is land. Differential Revision: https://reviews.llvm.org/D70443
* Recommit "[DWARF] Support for loclist.dwo section in llvm and llvm-dwarfdump."Sourabh Singh Tomar2019-11-231-0/+3
| | | | | | | | | | | The original commit message follows. This patch adds support for debug_loclists.dwo section in llvm and llvm-dwarfdump. Also Fixes PR43622, PR43623. Reviewers: dblaikie, probinson, labath, aprantl, jini.susan.george Differential Revision: https://reviews.llvm.org/D69462
* Revert "[DWARF] Support for loclist.dwo section in llvm and llvm-dwarfdump."Sourabh Singh Tomar2019-11-231-3/+0
| | | | | | This reverts commit 81b0a3284af1dcef26e56b0de9fd74002083c471. Will Re-apply, with updated Differtial Revision, for automatic closure of Phabricator review.
* [DWARF] Support for loclist.dwo section in llvm and llvm-dwarfdump.Sourabh Singh Tomar2019-11-231-0/+3
| | | | | | | | | This patch adds support for debug_loclists.dwo section in llvm and llvm-dwarfdump. Also Fixes PR43622, PR43623. Reviewers: dblaikie, probinson, labath, aprantl, jini.susan.george https://reviews.llvm.org/D69462
* [XCOFF][AIX] Read-only data section object file generationjasonliu2019-11-221-1/+6
| | | | | | | | | | Summary: This patch is a follow up on read-only assembly patch D70182. It intends to enable object file generation for the read-only data section on AIX. Reviewers: DiggerLin, daltenty Differential Revision: https://reviews.llvm.org/D70455
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-213-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* [AIX][XCOFF] Write Function descriptors and TOC base to data sectionjasonliu2019-11-191-6/+13
| | | | | | This patch implements writing function descriptors and TOC base into data section, and also add function descriptors(both csect and label) and TOC base symbols to the symbol table.
* MCObjectStreamer: assign MCSymbols in the dummy fragment to offset 0.James Y Knight2019-11-162-5/+20
| | | | | | | | | | | | | | | | | In MCObjectStreamer, when there is no current fragment, initially symbols are created in a "pending" state and assigned to a dummy empty fragment. Previously, they were not being assigned an offset, and thus evaluateAbsolute would fail if trying to evaluate an expression 'a - b', where both 'a' and 'b' were in this pending state. Also slightly refactored the EmitLabel overload which takes an MCFragment for clarity. Fixes: https://llvm.org/PR41825 Differential Revision: https://reviews.llvm.org/D70062
OpenPOWER on IntegriCloud