summaryrefslogtreecommitdiffstats
path: root/llvm/lib/MC
Commit message (Collapse)AuthorAgeFilesLines
* [DebugInfo] Some fields do not need relocations even relax is enabled.Hsiangkai Wang2019-07-191-2/+19
| | | | | | | | | | | | | | | | In debug frame information, some fields, e.g., Length in CIE/FDE and Offset in FDE are attributes to describe the structure of CIE/FDE. They are not related to the relaxed code. However, these attributes are symbol differences. So, in current design, these attributes will be filled as zero and LLVM generates relocations for them. We only need to generate relocations for symbols in executable sections. So, if the symbols are not located in executable sections, we still evaluate their values under relaxation. Differential Revision: https://reviews.llvm.org/D61584 llvm-svn: 366531
* [DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.Hsiangkai Wang2019-07-193-17/+63
| | | | | | | | | | | | | It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation. There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types. Differential Revision: https://reviews.llvm.org/D58335 llvm-svn: 366524
* Revert "[DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame."Hsiangkai Wang2019-07-183-63/+17
| | | | | | This reverts commit 17e3cbf5fe656483d9016d0ba9e1d0cd8629379e. llvm-svn: 366444
* [DebugInfo] Generate fixups as emitting DWARF .debug_frame/.eh_frame.Hsiangkai Wang2019-07-183-17/+63
| | | | | | | | | | | | | It is necessary to generate fixups in .debug_frame or .eh_frame as relaxation is enabled due to the address delta may be changed after relaxation. There is an opcode with 6-bits data in debug frame encoding. So, we also need 6-bits fixup types. Differential Revision: https://reviews.llvm.org/D58335 llvm-svn: 366442
* Changes to display code view debug info type records in hex formatNilanjana Basu2019-07-172-5/+17
| | | | llvm-svn: 366390
* [WebAssembly] Assembler: recognize .init_array as data section.Wouter van Oortmerssen2019-07-151-0/+3
| | | | | | | | | | | | Reviewers: sbc100 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64602 llvm-svn: 366104
* [macCatalyst] Use macCatalyst pretty name in .build_version darwinAlex Lorenz2019-07-122-2/+2
| | | | | | | | | assembly command 'macCatalyst' is more readable than 'maccatalyst'. I renamed the objdump output, but the assembly should match it as well. llvm-svn: 365964
* Delete dead storesFangrui Song2019-07-122-2/+0
| | | | llvm-svn: 365903
* Revert "[ELF] Loose a condition for relocation with a symbol"Nikola Prica2019-07-101-0/+5
| | | | | | | | This reverts commit 8507eca1647118e73435b0ce1de8a1952a021d01. Reveting due to some suspicious failurse in santizer-x86_64-linux. llvm-svn: 365685
* Revert "[System Model] [TTI] Update cache and prefetch TTI interfaces"David Greene2019-07-101-25/+0
| | | | | | | | This broke some PPC prefetching tests. This reverts commit 9fdfb045ae8bb643ab0d0455dcf9ecaea3b1eb3c. llvm-svn: 365680
* [System Model] [TTI] Update cache and prefetch TTI interfacesDavid Greene2019-07-101-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rework the TTI cache and software prefetching APIs to prepare for the introduction of a general system model. Changes include: - Marking existing interfaces const and/or override as appropriate - Adding comments - Adding BasicTTIImpl interfaces that delegate to a subtarget implementation - Adding a default "no information" subtarget implementation Only a handful of targets use these interfaces currently: AArch64, Hexagon, PPC and SystemZ. AArch64 already has a custom subtarget implementation, so its custom TTI implementation is migrated to use the new facilities in BasicTTIImpl to invoke its custom subtarget implementation. The custom TTI implementations continue to exist for the other targets with this change. They are not moved over to subtarget-based implementations. The end goal is to have the default subtarget implementation defer to the system model defined by the target. With this change, the default subtarget implementation essentially returns "no information" for these interfaces. None of the existing users of TTI will hit that implementation because they define their own custom TTI implementations and won't use the BasicTTIImpl implementations. Once system models are in place for the targets that use these interfaces, their custom TTI implementations can be removed. Differential Revision: https://reviews.llvm.org/D63614 llvm-svn: 365676
* [ELF] Loose a condition for relocation with a symbolNikola Prica2019-07-101-5/+0
| | | | | | | | | | | | | | | | | Deleted code was introduced as a work around for a bug in the gold linker (http://sourceware.org/PR16794). Test case that was given as a reason for this part of code, the one on previous link, now works for the gold. This condition is too strict and when a code is compiled with debug info it forces generation of numerous relocations with symbol for architectures that do not have relocation addend. Reviewers: arsenm, espindola Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D64327 llvm-svn: 365618
* Fix build error for VC STL, use llvm::make_uniqueReid Kleckner2019-07-091-1/+1
| | | | llvm-svn: 365548
* Boilerplate for producing XCOFF object files from the PowerPC backend.Sean Fertile2019-07-099-2/+275
| | | | | | | | | | Stubs out a number of the classes needed to produce a new object file format (XCOFF) for the powerpc-aix target. For testing input is an empty module which produces an object file with just a file header. Differential Revision: https://reviews.llvm.org/D61694 llvm-svn: 365541
* Standardize on MSVC behavior for triples with no environmentReid Kleckner2019-07-081-2/+2
| | | | | | | | | | | | | | | | | | | | | Summary: This makes it so that IR files using triples without an environment work out of the box, without normalizing them. Typically, the MSVC behavior is more desirable. For example, it tends to enable things like constant merging, use of associative comdats, etc. Addresses PR42491 Reviewers: compnerd Subscribers: hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64109 llvm-svn: 365387
* Add support for the 'macCatalyst' MachO platformAlex Lorenz2019-07-023-0/+12
| | | | | | | | | Mac Catalyst is a new MachO platform in macOS Catalina. It always uses the build_version MachO load command. Differential Revision: https://reviews.llvm.org/D64107 llvm-svn: 364981
* [WebAssembly] Allow @object in .type directives.Wouter van Oortmerssen2019-06-281-0/+2
| | | | | | | | | | | | Reviewers: sbc100 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63955 llvm-svn: 364688
* [WebAssembly] Assembler: Improve section parsing.Wouter van Oortmerssen2019-06-281-29/+14
| | | | | | | | | | | | Reviewers: sbc100 Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63947 llvm-svn: 364681
* [WebAssembly] Added visibility and ident directives to WasmAsmParser.Wouter van Oortmerssen2019-06-281-0/+54
| | | | | | | | | | | | | | | | | Summary: These are output by clang -S, so can now be roundtripped thru clang. (partially) fixes: https://bugs.llvm.org/show_bug.cgi?id=34544 Reviewers: dschuff Subscribers: sbc100, jgravelle-google, aheejin, sunfish, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63901 llvm-svn: 364658
* Fix leaks in LLVMCreateDisasmCPUFeaturesScott Linder2019-06-262-31/+31
| | | | | | Differential Revision: https://reviews.llvm.org/D63795 llvm-svn: 364444
* MC: correct the emission of weak aliases in COFFSaleem Abdulrasool2019-06-261-1/+1
| | | | | | | | | | | The weak alias should have the characteristics set to `IMAGE_EXTERN_WEAK_SEARCH_ALIAS` to indicate that the weak external here is a symbol alias and that the symbol is aliased to a locally defined symbol. We were previously setting the characteristics to `IMAGE_EXTERN_WEAK_SEARCH_LIBRARY` which indicates that the symbol should be looked for in the libraries. llvm-svn: 364370
* [WebAssembly] Fix list of relocations with addends in lldKeno Fischer2019-06-261-13/+1
| | | | | | | | | | | | | Summary: The list of relocations with addend in lld was missing `R_WASM_MEMORY_ADDR_REL_SLEB`, causing `wasm-ld` to generate corrupted output. This fixes that problem and while we're at it pulls the list of such relocations into the Wasm.h header, to avoid duplicating it in multiple places. Reviewers: sbc100 Differential Revision: https://reviews.llvm.org/D63696 llvm-svn: 364367
* AMDGPU/MC: Add .amdgpu_lds directiveNicolai Haehnle2019-06-251-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The directive defines a symbol as an group/local memory (LDS) symbol. LDS symbols behave similar to common symbols for the purposes of ELF, using the processor-specific SHN_AMDGPU_LDS as section index. It is the linker and/or runtime loader's job to "instantiate" LDS symbols and resolve relocations that reference them. It is not possible to initialize LDS memory (not even zero-initialize as for .bss). We want to be able to link together objects -- starting with relocatable objects, but possible expanding to shared objects in the future -- that access LDS memory in a flexible way. LDS memory is in an address space that is entirely separate from the address space that contains the program image (code and normal data), so having program segments for it doesn't really make sense. Furthermore, we want to be able to compile multiple kernels in a compilation unit which have disjoint use of LDS memory. In that case, we may want to place LDS symbols differently for different kernels to save memory (LDS memory is very limited and physically private to each kernel invocation), so we can't simply place LDS symbols in a .lds section. Hence this solution where LDS symbols always stay undefined. Change-Id: I08cbc37a7c0c32f53f7b6123aa0afc91dbc1748f Reviewers: arsenm, rampitec, t-tye, b-sumner, jsjodin Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61493 llvm-svn: 364296
* Fix a crash with assembler source and -g.Paul Robinson2019-06-211-2/+2
| | | | | | | | | | | | | | | llvm-mc or clang with -g normally produces debug info describing the assembler source itself; however, if that source already contains some .file/.loc directives, we should instead emit the debug info described by those directives. For certain assembler sources seen in the wild (particularly in the Chrome build) this was causing a crash due to incorrect assumptions about legal sequences of assembler source text. Fixes PR38994. Differential Revision: https://reviews.llvm.org/D63573 llvm-svn: 364039
* Simplify std::lower_bound with llvm::{bsearch,lower_bound}. NFCFangrui Song2019-06-211-1/+1
| | | | llvm-svn: 364006
* MCContext: Delete unused functionsFangrui Song2019-06-181-8/+0
| | | | llvm-svn: 363674
* AMDGPU: Prepare for explicit absolute relocations in code generationNicolai Haehnle2019-06-161-0/+4
| | | | | | | | | | | | | | | | | Summary: We will use absolute relocations for LDS symbols. Change-Id: I9a32795ed0ea835e433a787129cfe3c57ee9a325 Reviewers: arsenm, rampitec Subscribers: kzhuravl, jvesely, wdng, yaxunl, dstuttard, tpr, t-tye, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61492 llvm-svn: 363517
* Add --print-supported-cpus flag for clang.Ziang Wan2019-06-141-1/+34
| | | | | | | | | | | | This patch allows clang users to print out a list of supported CPU models using clang [--target=<target triple>] --print-supported-cpus Then, users can select the CPU model to compile to using clang --target=<triple> -mcpu=<model> a.c It is a handy feature to help cross compilation. llvm-svn: 363464
* [MC][ELF] Don't create relocations with section symbols for STB_LOCAL ifuncFangrui Song2019-06-071-0/+6
| | | | | | | | | | | We should keep the symbol type (STT_GNU_IFUNC) for a local ifunc because it may result in an IRELATIVE reloc that the dynamic loader will use to resolve the address at startup time. There is another problem that is not fixed by this patch: a PC relative relocation should also create a relocation with the ifunc symbol. llvm-svn: 362767
* [AIX] Implement function descriptor on SDAGJason Liu2019-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (1) Function descriptor on AIX On AIX, a called routine may have 2 distinct symbols associated with it: * A function descriptor (Name) * A function entry point (.Name) The descriptor structure on AIX is the same as those in the ELF V1 ABI: * The address of the entry point of the function. * The TOC base address for the function. * The environment pointer. The descriptor symbol uses the same name as the source level function in C. The function entry point is analogous to the symbol we would generate for a function in a non-descriptor-based ABI, except that it is renamed by prepending a ".". Which symbol gets referenced depends on the context: * Taking the address of the function references the descriptor symbol. * Calling the function references the entry point symbol. (2) Speaking of implementation on AIX, for direct function call target, we create proper MCSymbol SDNode(e.g . ".foo") while constructing SDAG to replace original TargetGlobalAddress SDNode. Then down the path, we can take advantage of this MCSymbol. Patch by: Xiangling_L Reviewed by: sfertile, hubert.reinterpretcast, jasonliu, syzaara Differential Revision: https://reviews.llvm.org/D62532 llvm-svn: 362735
* [codeview] Revert inline line table change of r362264Reid Kleckner2019-05-311-0/+1
| | | | | | | | | | | | Testing with debuggers shows that our previous behavior was correct. The reason I thought MSVC did things differently is that MSVC prefers to use the 0xB combined code offset and code length update opcode when inline sites are discontiguous. Keep the test changes, and update the llvm-pdbutil inline line table dumper to account for this new interpretation of the opcodes. llvm-svn: 362277
* [codeview] Fix inline line table accuracy for discontiguous segmentsReid Kleckner2019-05-311-1/+0
| | | | | | | | | | | | | | | | After improving the inline line table dumper in llvm-pdbutil and looking at MSVC's inline line tables, it is clear that setting the length of the inlined code region does not update the code offset. This means that the delta to the beginning of a new discontiguous inlined code region should be calculated relative to the last code offset, excluding the length. Implementing this is a one line fix for MC: simply don't update LastLabel. While I'm updating these test cases, switch them to use llvm-objdump -d and llvm-pdbutil. This allows us to show offsets of each instruction and correlate the line table offsets to the actual code. llvm-svn: 362264
* Add IR support, ELF section and user documentation for partitioning feature.Peter Collingbourne2019-05-292-0/+4
| | | | | | | | | | | | The partitioning feature was proposed here: http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html This is mostly just documentation. The feature itself will be contributed in subsequent patches. Differential Revision: https://reviews.llvm.org/D60242 llvm-svn: 361923
* [X86] Fix x86-64 call *foo@tlsdesc(%rax) and support R_386_TLSGOTDESC ↵Fangrui Song2019-05-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | R_386_TLS_DESC_CALL D18885 emitted 5 bytes for call *foo@tlsdesc(%rax). It should use the 2-byte form instead and let R_X86_64_TLSDESC_CALL apply to the beginning of the call instruction. The 2-byte form was deliberately chosen to make ->LE and ->IE relaxation work: 0: 48 8d 05 00 00 00 00 lea 0x0(%rip),%rax # 7 <.text+0x7> 3: R_X86_64_GOTPC32_TLSDESC a-0x4 7: ff 10 callq *(%rax) 7: R_X86_64_TLSDESC_CALL a => 0: 48 c7 c0 fc ff ff ff mov $0xfffffffffffffffc,%rax 7: 66 90 xchg %ax,%ax Also change the symbol type to STT_TLS when VK_TLSCALL or VK_TLSDESC is seen. Reviewed By: compnerd Differential Revision: https://reviews.llvm.org/D62512 llvm-svn: 361910
* [ARM] Replace fp-only-sp and d16 with fp64 and d32.Simon Tatham2019-05-281-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those two subtarget features were awkward because their semantics are reversed: each one indicates the _lack_ of support for something in the architecture, rather than the presence. As a consequence, you don't get the behavior you want if you combine two sets of feature bits. Each SubtargetFeature for an FP architecture version now comes in four versions, one for each combination of those options. So you can still say (for example) '+vfp2' in a feature string and it will mean what it's always meant, but there's a new string '+vfp2d16sp' meaning the version without those extra options. A lot of this change is just mechanically replacing positive checks for the old features with negative checks for the new ones. But one more interesting change is that I've rearranged getFPUFeatures() so that the main FPU feature is appended to the output list *before* rather than after the features derived from the Restriction field, so that -fp64 and -d32 can override defaults added by the main feature. Reviewers: dmgreen, samparker, SjoerdMeijer Subscribers: srhines, javed.absar, eraman, kristof.beyls, hiraditya, zzheng, Petar.Avramovic, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D60691 llvm-svn: 361845
* [DebugInfo] Handle '# line "file"' correctly for asm source.Paul Robinson2019-05-211-1/+14
| | | | | | | | | | | This provides the correct file path for the original source, rather than the preprocessed source. Part of the fix for PR41839. Differential Revision: https://reviews.llvm.org/D62074 llvm-svn: 361248
* [DebugInfo] Handle -main-file-name correctly for asm source.Paul Robinson2019-05-211-4/+15
| | | | | | | | | | This option provides only the base filename, not a full relative path. Part of the fix for PR41839. Differential Revision: https://reviews.llvm.org/D62071 llvm-svn: 361245
* [ELF] Implement Dependent Libraries FeatureBen Dunbobbin2019-05-172-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements a limited form of autolinking primarily designed to allow either the --dependent-library compiler option, or "comment lib" pragmas ( https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically add the specified library to the link when processing the input file generated by the compiler. Currently this extension is unique to LLVM and LLD. However, care has been taken to design this feature so that it could be supported by other ELF linkers. The design goals were to provide: - A simple linking model for developers to reason about. - The ability to to override autolinking from the linker command line. - Source code compatibility, where possible, with "comment lib" pragmas in other environments (MSVC in particular). Dependent library support is implemented differently for ELF platforms than on the other platforms. Primarily this difference is that on ELF we pass the dependent library specifiers directly to the linker without manipulating them. This is in contrast to other platforms where they are mapped to a specific linker option by the compiler. This difference is a result of the greater variety of ELF linkers and the fact that ELF linkers tend to handle libraries in a more complicated fashion than on other platforms. This forces us to defer handling the specifiers to the linker. In order to achieve a level of source code compatibility with other platforms we have restricted this feature to work with libraries that meet the following "reasonable" requirements: 1. There are no competing defined symbols in a given set of libraries, or if they exist, the program owner doesn't care which is linked to their program. 2. There may be circular dependencies between libraries. The binary representation is a mergeable string section (SHF_MERGE, SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES (0x6fff4c04). The compiler forms this section by concatenating the arguments of the "comment lib" pragmas and --dependent-library options in the order they are encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs sections with the normal mergeable string section rules. As an example, #pragma comment(lib, "foo") would result in: .section ".deplibs","MS",@llvm_dependent_libraries,1 .asciz "foo" For LTO, equivalent information to the contents of a the .deplibs section can be retrieved by the LLD for bitcode input files. LLD processes the dependent library specifiers in the following way: 1. Dependent libraries which are found from the specifiers in .deplibs sections of relocatable object files are added when the linker decides to include that file (which could itself be in a library) in the link. Dependent libraries behave as if they were appended to the command line after all other options. As a consequence the set of dependent libraries are searched last to resolve symbols. 2. It is an error if a file cannot be found for a given specifier. 3. Any command line options in effect at the end of the command line parsing apply to the dependent libraries, e.g. --whole-archive. 4. The linker tries to add a library or relocatable object file from each of the strings in a .deplibs section by; first, handling the string as if it was specified on the command line; second, by looking for the string in each of the library search paths in turn; third, by looking for a lib<string>.a or lib<string>.so (depending on the current mode of the linker) in each of the library search paths. 5. A new command line option --no-dependent-libraries tells LLD to ignore the dependent libraries. Rationale for the above points: 1. Adding the dependent libraries last makes the process simple to understand from a developers perspective. All linkers are able to implement this scheme. 2. Error-ing for libraries that are not found seems like better behavior than failing the link during symbol resolution. 3. It seems useful for the user to be able to apply command line options which will affect all of the dependent libraries. There is a potential problem of surprise for developers, who might not realize that these options would apply to these "invisible" input files; however, despite the potential for surprise, this is easy for developers to reason about and gives developers the control that they may require. 4. This algorithm takes into account all of the different ways that ELF linkers find input files. The different search methods are tried by the linker in most obvious to least obvious order. 5. I considered adding finer grained control over which dependent libraries were ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this is not necessary: if finer control is required developers can fall back to using the command line directly. RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html. Differential Revision: https://reviews.llvm.org/D60274 llvm-svn: 360984
* [ARM] Support .reloc *, R_ARM_NONE, *Fangrui Song2019-05-171-0/+1
| | | | | | | | | | | | | | | | R_ARM_NONE can be used to create references among sections. When --gc-sections is used, the referenced section will be retained if the origin section is retained. Add a generic MCFixupKind FK_NONE as this kind of no-op relocation is ubiquitous on ELF and COFF, and probably available on many other binary formats. See D62014. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D61992 llvm-svn: 360980
* [MC][ELF] Copy top 3 bits of st_other to .symver aliasesFangrui Song2019-05-101-0/+1
| | | | | | | | | | | | | | | On PowerPC64 ELFv2 ABI, the top 3 bits of st_other encode the local entry offset. A versioned symbol alias created by .symver should copy the bits from the source symbol. This partly fixes PR41048. A full fix needs tracking of .set assignments and updating st_other fields when finish() is called, see D56586. Patch by Alfredo Dal'Ava Júnior Differential Revision: https://reviews.llvm.org/D59436 llvm-svn: 360442
* [AArch64][Windows] Compute function length correctly in unwind tables.Eli Friedman2019-05-031-6/+43
| | | | | | | | | | | | | | | | | | | | | | The primary fix here is to WinException.cpp: we need to exclude jump tables when computing the length of a function, or else we fail to correctly compute the length. (We can only compute the number of bytes consumed by certain assembler directives after the entire file is parsed. ".p2align" is one of those directives, and is used by jump table generation.) The secondary fix, to MCWin64EH, is to make sure we don't silently miscompile if we hit a similar situation in the future. It's possible we could extend ARM64EmitUnwindInfo so it allows function bodies that contain assembler directives, but that's a lot more complicated; see the FIXME in MCWin64EH.cpp. Fixes https://bugs.llvm.org/show_bug.cgi?id=41581 . Differential Revision: https://reviews.llvm.org/D61095 llvm-svn: 359849
* Use llvm::stable_sortFangrui Song2019-04-232-8/+6
| | | | | | While touching the code, simplify if feasible. llvm-svn: 358996
* [llvm-mc] - Properly set the the address align field of the compressed sections.George Rimar2019-04-231-2/+6
| | | | | | | | | | | | | | | | | | | | | About the compressed sections spec says: (https://docs.oracle.com/cd/E37838_01/html/E36783/section_compression.html) sh_addralign fields of the section header for a compressed section reflect the requirements of the compressed section. Currently, llvm-mc always puts uncompressed section alignment to sh_addralign. It is not correct. zlib styled section contains an Elfxx_Chdr header, so we should either use 4 or 8 values depending on the target (Uncompressed section alignment is stored in ch_addralign field of the compression header). GNU assembler version 2.31.1 also has this issue, but in 2.32.51 it was already fixed. This is how it was found during debugging of the https://bugs.llvm.org/show_bug.cgi?id=40482 actually. Differential revision: https://reviews.llvm.org/D60965 llvm-svn: 358960
* [llvm] Prevent duplicate files in debug line header in dwarf 5: another attemptAli Tamur2019-04-193-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Another attempt to land the changes in debug line header to prevent duplicate files in Dwarf 5. I rolled back my previous commit because of a mistake in generating the object file in a test. Meanwhile, I addressed some offline comments and changed the implementation; the largest difference is that MCDwarfLineTableHeader does not keep DwarfVersion but gets it as a parameter. I also merged the patch to fix two lld tests that will strt to fail into this patch. Original Commit: https://reviews.llvm.org/D59515 Original Message: 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. llvm-svn: 358732
* [WebAssembly] Add DataCount section to object filesThomas Lively2019-04-121-0/+12
| | | | | | | | | | | | | | | | | | | Summary: This ensures that object files will continue to validate as WebAssembly modules in the presence of bulk memory operations. Engines that don't support bulk memory operations will not recognize the DataCount section and will report validation errors, but that's ok because object files aren't supposed to be run directly anyway. Reviewers: aheejin, dschuff, sbc100 Subscribers: jgravelle-google, hiraditya, sunfish, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D60623 llvm-svn: 358315
* Move getNumFrameInfos and getDwarfFrameInfos out of line and removeEric Christopher2019-04-121-0/+5
| | | | | | | | | | | the MCDwarf.h include. This removes 50 transitive dependencies for a modification of MCDwarf.h in a build of llc for a pair of out of line functions and reduces the build overhead of 'touch MCDwarf.h" by 15% without impacting test time of check-llvm. llvm-svn: 358264
* Move addInitialFrameState out of line and remove the MCDwarf.h include.Eric Christopher2019-04-121-0/+4
| | | | | | | | | This removes 50 transitive dependencies for a modification of MCDwarf.h in a build of llc for a single out of line function and reduces the build overhead by 20% without impacting test time of check-llvm. llvm-svn: 358258
* MCDwarfLineTableheader::tryGetFile : replace a loop with llvm::findFangrui Song2019-04-121-5/+1
| | | | | | | Note, `DirIndex++` below is incorrect for DWARF 5, but it can be fixed later after the file index is fixed. llvm-svn: 358251
* Move a couple of optional references to just optional to make theEric Christopher2019-04-121-1/+1
| | | | | | forwarding APIs look similar. llvm-svn: 358250
* [MC] Fix typo: .symtab_shndxr -> .symtab_shndxFangrui Song2019-04-121-1/+1
| | | | | | | | | This special section is named .symtab_shndx, according to gABI Chapter 4 Sections, and the name is used by some other tools. Though the section type SHT_SYMTAB_SHNDX is what really matters, let's fix the typo introduced in rL204769 :) llvm-svn: 358247
OpenPOWER on IntegriCloud