summaryrefslogtreecommitdiffstats
path: root/llvm/test/MC/COFF
Commit message (Collapse)AuthorAgeFilesLines
* Revert "[COFF] Make the autogenerated .weak.<name>.default symbols static"Martin Storsjö2019-12-283-4/+4
| | | | | | | 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-283-4/+4
| | | | | | | | | | | | | | 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
* Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" ↵Fangrui Song2019-12-241-1/+1
| | | | as cleanups after D56351
* [MC] Produce proper section relative relocations for COFF in .debug_frameMartin Storsjö2019-11-271-0/+26
| | | | | | | | | | | | | 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
* [llvm-objdump] Further rearrange llvm-objdump sections for compatabilityJordan Rupprecht2019-10-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: rL371826 rearranged some output from llvm-objdump for GNU objdump compatability, but there still seem to be some more. I think this rearrangement is a little closer. Overview of the ordering which matches GNU objdump: * Archive headers * File headers * Section headers * Symbol table * Dwarf debugging * Relocations (if `--disassemble` is not used) * Section contents * Disassembly Reviewers: jhenderson, justice_adams, grimar, ychen, espindola Reviewed By: jhenderson Subscribers: aprantl, emaste, arichardson, jrtc27, atanasyan, seiya, llvm-commits, MaskRay Tags: #llvm Differential Revision: https://reviews.llvm.org/D68066 llvm-svn: 373671
* [X86] Print register names in .seh_* directivesReid Kleckner2019-08-303-5/+5
| | | | | | | | | | Also improve assembler parser register validation for .seh_ directives. This requires moving X86-specific seh directive handling into the x86 backend, which addresses some assembler FIXMEs. Differential Revision: https://reviews.llvm.org/D66625 llvm-svn: 370533
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-054-5/+100
| | | | | | assembly format for better readability llvm-svn: 367867
* Revert "Changing representation of .cv_def_range directives in Codeview ↵Nilanjana Basu2019-08-053-5/+5
| | | | | | | | debug info assembly format for better readability" This reverts commit a885afa9fa8cab3b34f1ddf3d21535f88b662881. llvm-svn: 367861
* Changing representation of .cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-053-5/+5
| | | | | | assembly format for better readability llvm-svn: 367850
* Temporarily Revert "Changing representation of cv_def_range directives in ↵Eric Christopher2019-08-024-100/+5
| | | | | | | | | | Codeview debug info assembly format for better readability" This is breaking bots and the author asked me to revert. This reverts commit 367704. llvm-svn: 367707
* Changing representation of cv_def_range directives in Codeview debug info ↵Nilanjana Basu2019-08-024-5/+100
| | | | | | assembly format for better readability llvm-svn: 367704
* MC: correct the emission of weak aliases in COFFSaleem Abdulrasool2019-06-264-5/+5
| | | | | | | | | | | 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
* [llvm-objdump] Use %08 instead of %016 to print leading addresses for 32-bit ↵Fangrui Song2019-06-172-2/+2
| | | | | | | | | | binaries Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D63398 llvm-svn: 363539
* [lit] Delete empty lines at the end of lit.local.cfg NFCFangrui Song2019-06-172-2/+0
| | | | llvm-svn: 363538
* [codeview] Revert inline line table change of r362264Reid Kleckner2019-05-313-5/+4
| | | | | | | | | | | | 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-314-50/+77
| | | | | | | | | | | | | | | | 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
* [llvm-pdbutil] Dump inline call site line table annotationsReid Kleckner2019-05-291-1/+38
| | | | | | | | | This ports and improves on some existing llvm-readobj -codeview dumping functionality that llvm-pdbutil lacked. Helpful for comparing inline line tables between MSVC and clang. llvm-svn: 362037
* [llvm-readobj] Change -t to --symbols in tests. NFCFangrui Song2019-05-0117-22/+22
| | | | | | | | | | -t is --symbols in llvm-readobj but --section-details (unimplemented) in readelf. The confusing option should not be used since we aim for improving compatibility. Keep just one llvm-readobj -t use case in test/tools/llvm-readobj/symbols.test llvm-svn: 359661
* [llvm-readobj] Change -long-option to --long-option in tests. NFCFangrui Song2019-05-0146-52/+52
| | | | | | | | | | We use both -long-option and --long-option in tests. Switch to --long-option for consistency. In the "llvm-readelf" mode, -long-option is discouraged as it conflicts with grouped short options and it is not accepted by GNU readelf. While updating the tests, change llvm-readobj -s to llvm-readobj -S to reduce confusion ("s" is --section-headers in llvm-readobj but --symbols in llvm-readelf). llvm-svn: 359649
* [llvm-objdump] - Print LMAs when dumping section headers.George Rimar2019-01-281-1/+1
| | | | | | | | | | | | When --section-headers is used, GNU objdump prints both LMA and VMA for sections. llvm-objdump does not do that what makes it's output be slightly inconsistent. Patch teaches llvm-objdump to print LMA/VMA for ELF file formats. The behavior for other formats remains unchanged. Differential revision: https://reviews.llvm.org/D57146 llvm-svn: 352366
* simplify COFF module assembly test and move it to ObjectBob Haarman2019-01-251-21/+0
| | | | | | | | | | Reviewers: pcc, rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D57192 llvm-svn: 352142
* allow COFF .def directive in module assembly when using ThinLTOBob Haarman2019-01-241-0/+21
| | | | | | | | | | | | | | | | | | | | Summary: Using COFF's .def directive in module assembly used to crash ThinLTO with "this directive only supported on COFF targets" when getting symbol information in ModuleSymbolTable. This change allows ModuleSymbolTable to process such code and adds a test to verify that the .def directive has the desired effect on the native object file, with and without ThinLTO. Fixes https://bugs.llvm.org/show_bug.cgi?id=36789 Reviewers: rnk, pcc, vlad.tsyrklevich Subscribers: mehdi_amini, eraman, hiraditya, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D57073 llvm-svn: 352112
* Python compat - print statementSerge Guelton2019-01-031-0/+2
| | | | | | | | | Make sure all print statements are compatible with Python 2 and Python3 using the `from __future__ import print_function` statement. Differential Revision: https://reviews.llvm.org/D56249 llvm-svn: 350307
* [llvm-readobj] [COFF] Print the symbol index for relocationsMartin Storsjo2019-01-031-0/+4
| | | | | | | | | | There can be multiple local symbols with the same name (for e.g. comdat sections), and thus the symbol name itself isn't enough to disambiguate symbols. Differential Revision: https://reviews.llvm.org/D56140 llvm-svn: 350288
* [MC] Enable .file support on COFF and diagnose it on unsupported targetsReid Kleckner2018-12-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The "single parameter" .file directive appears to be an ELF-only feature that is intended to insert the main source filename into the string table table. I noticed that if you assemble an ELF .s file for COFF, typically it will assert right away on a .file directive near the top of the file. My first change was to make this emit a proper error in the asm parser so that we don't assert so easily. However, COFF actually does have some support for this directive, and if you emit an object file, llvm-mc does not assert. When emitting a COFF object, MC will take those file names and create "debug" symbol table entries for them. I'm not familiar with these kinds of symbol table entries, and I'm not aware of any users of them, but @compnerd added them a while ago. They don't introduce absolute paths, and most main source file paths are short enough that this extra entry shouldn't cause any problems, so I enabled the flag in MCAsmInfoCOFF that indicates that it's supported. This has the side effect of adding an extra debug symbol to every object produced by clang, which is a pretty big functional change. My question is, should we keep the functionality or remove it in the name of symbol table minimalism? Reviewers: mstorsjo, compnerd Subscribers: hiraditya, compnerd, llvm-commits Differential Revision: https://reviews.llvm.org/D55900 llvm-svn: 349976
* [codeview] Flush labels before S_DEFRANGE* fragmentsReid Kleckner2018-12-171-0/+161
| | | | | | | | | | | | | This was a pre-existing bug that could be triggered with assembly like this: .p2align 2 .LtmpN: .cv_def_range "..." I noticed this when attempting to change clang to emit aligned symbol records. llvm-svn: 349403
* [COFF] Don't mark mingw .eh_frame sections writableMartin Storsjo2018-12-031-0/+13
| | | | | | | | | | | | | | This improves compatibility with GCC produced object files, where the .eh_frame sections are read only. With mixed flags for the involved .eh_frame sections, LLD creates two separate .eh_frame sections in the output binary, one for each flag combination, while ld.bfd probably merges them. The previous setup of flags can be traced back to SVN r79346. Differential Revision: https://reviews.llvm.org/D55209 llvm-svn: 348177
* [COFF] [X86] Don't use llvm_unreachable for unsupported relocation typesMartin Storsjo2018-10-041-0/+5
| | | | | | | | | | | | | | | | This can happen if assembling a reference to _GLOBAL_OFFSET_TABLE_. While it doesn't make sense to try to assemble that for COFF, the fact that we previously used llvm_unreachable meant that the code had undefined behaviour if something tried to assemble that. The configure script of libgmp would try to assemble such a snippet (which should signal a failure). If llvm is built without assertions, the undefined behaviour meant a (near) infinite loop. Differential Revision: https://reviews.llvm.org/D52903 llvm-svn: 343811
* [codeview] Fix 32-bit x86 variable locations in realigned stack framesReid Kleckner2018-10-021-0/+199
| | | | | | | | | | | | | | | | | | Add the .cv_fpo_stackalign directive so that we can define $T0, or the VFRAME virtual register, with it. This was overlooked in the initial implementation because unlike MSVC, we push CSRs before allocating stack space, so this value is only needed to describe local variable locations. Variables that the compiler now addresses via ESP are instead described as being stored at offsets from VFRAME, which for us is ESP after alignment in the prologue. This adds tests that show that we use the VFRAME register properly in our S_DEFRANGE records, and that we emit the correct FPO data to define it. Fixes PR38857 llvm-svn: 343603
* [codeview] Add .cv_string directive for testing purposesReid Kleckner2018-09-071-0/+69
| | | | | | | | | | | The main use case for this directive is to allow assembly writers to write their own FPO data strings without going through the .cv_fpo* directive family. I'm experimenting with different RPN programs to fix PR38857, and I figured I should go ahead and make this directive permanent. llvm-svn: 341712
* [codeview] Improve readobj FPO dumper and pdbutil register namesReid Kleckner2018-09-072-12/+85
| | | | | | The improved dumping helps me investigate PR38857. llvm-svn: 341695
* [codeview] Emit labels for .cv_loc immediatelyReid Kleckner2018-08-282-4/+177
| | | | | | | | | | | | | | | Previously we followed the DWARF implementation, which waits until the next instruction or data to emit the label to use in the .debug_loc section. We might want to consider re-evaluating that design choice as well, since it means the .loc skips alignment padding, for better or worse. This was the most minimal fix I could come up with, but we should be able to do a lot of cleanups now that we don't need to save a pending CV location on the CodeViewContext. I plan to do those next, but this immediately fixes an assertion for some of our users. llvm-svn: 340878
* MC: Don't align COFF section contents.Peter Collingbourne2018-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Aligning section contents is not required, but only recommended, by the specification. Microsoft's documentation says (https://docs.microsoft.com/en-us/windows/desktop/debug/pe-format#section-table-section-headers): "For object files, the value should be aligned on a 4-byte boundary for best performance." However, according to my measurements, aligning section contents has a neutral to negative effect on performance. I measured the median run time of 100 links of Chromium's base_unittests on Linux with lld-link and on Windows with link.exe with both aligned and unaligned sections. On Linux I didn't see a measurable performance difference, and on Windows the link was slightly faster with unaligned sections (presumably because on Windows the bottleneck is I/O). Also, the sections created by cl.exe are unaligned, so we should expect tools to broadly accept unaligned sections. Differential Revision: https://reviews.llvm.org/D51149 llvm-svn: 340514
* MC: Teach the COFF object writer to write address-significance tables.Peter Collingbourne2018-08-221-0/+51
| | | | | | | | | The format is the same as in ELF: a sequence of ULEB128-encoded symbol indexes. Differential Revision: https://reviews.llvm.org/D51047 llvm-svn: 340499
* [MC] Improve COFF associative section lookupReid Kleckner2018-08-163-0/+36
| | | | | | | | | | | | | | | Handle the case when the symbol is private. Private symbols are not in the COFF object file symbol table, so they aren't inserted into SymbolMap. We can't look up the section of the symbol that way. Instead, get the MCSection from the MCSymbol and map that to the object file section. Print a better error message when the symbol has no section, like when the symbol is undefined. Fixes PR38607 llvm-svn: 339942
* [codeview] Use push_macro to avoid conflicts instead of a prefixReid Kleckner2018-08-161-4/+4
| | | | | | | | | | | | | | | | | | | | | | | 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
* [MC] Add support for the .rva assembler directive for COFF targetsMartin Storsjo2018-07-261-2/+32
| | | | | | | | | | | | | Even though gas doesn't document it, it has been supported there for a very long time. This produces the 32 bit relative virtual address (aka image relative address) for a given symbol. ".rva foo" is essentially equal to ".long foo@imgrel". Differential Revision: https://reviews.llvm.org/D49821 llvm-svn: 338063
* [CodeView] Add prefix to CodeView registers.Jonas Devlieghere2018-05-291-4/+4
| | | | | | | | | | | | | Adds CVReg to CodeView register names to prevent a duplicate symbol with CR3 defined in termios.h, as suggested by Zachary on the mailing list. http://lists.llvm.org/pipermail/llvm-dev/2018-May/123372.html Differential revision: https://reviews.llvm.org/D47478 rdar://39863705 llvm-svn: 333421
* [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.Shiva Chen2018-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to set breakpoints on labels and list source code around labels, we need collect debug information for labels, i.e., label name, the function label belong, line number in the file, and the address label located. In order to keep these information in LLVM IR and to allow backend to generate debug information correctly. We create a new kind of metadata for labels, DILabel. The format of DILabel is !DILabel(scope: !1, name: "foo", file: !2, line: 3) We hope to keep debug information as much as possible even the code is optimized. So, we create a new kind of intrinsic for label metadata to avoid the metadata is eliminated with basic block. The intrinsic will keep existing if we keep it from optimized out. The format of the intrinsic is llvm.dbg.label(metadata !1) It has only one argument, that is the DILabel metadata. The intrinsic will follow the label immediately. Backend could get the label metadata through the intrinsic's parameter. We also create DIBuilder API for labels to be used by Frontend. Frontend could use createLabel() to allocate DILabel objects, and use insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR. Differential Revision: https://reviews.llvm.org/D45024 Patch by Hsiangkai Wang. llvm-svn: 331841
* [codeview] Ignore .cv_loc directives at the end of a functionReid Kleckner2018-04-251-0/+183
| | | | | | | | | | If no data or instructions are emitted after a location directive, we should clear the cv_loc when we change sections, or it will be emitted at the beginning of the next section. This violates our invariant that all .cv_loc directives belong to the same section. Add clearer assertions for this. llvm-svn: 330884
* [IR] Avoid the need to prefix MS C++ symbols with '\01'Reid Kleckner2018-03-161-17/+0
| | | | | | | | | | | | | | | | | | | | Now the Windows mangling modes ('w' and 'x') do not do any mangling for symbols starting with '?'. This means that clang can stop adding the hideous '\01' leading escape. This means LLVM debug logs are less likely to contain ASCII escape characters and it will be easier to copy and paste MS symbol names from IR. Finally. For non-Windows platforms, names starting with '?' still get IR mangling, so once clang stops escaping MS C++ names, we will get extra '_' prefixing on MachO. That's fine, since it is currently impossible to construct a triple that uses the MS C++ ABI in clang and emits macho object files. Differential Revision: https://reviews.llvm.org/D7775 llvm-svn: 327734
* [MC] Always emit relocations for same-section function referencesReid Kleckner2018-03-141-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We already emit relocations in this case when the "incremental linker compatible" flag is set, but it turns out these relocations are also required for /guard:cf. Now that we have two use cases for this behavior, let's make it unconditional to try to keep things simple. We never hit this problem in Clang because it always sets the "incremental linker compatible" flag when targeting MSVC. However, LLD LTO doesn't set this flag, so we'd get CFG failures at runtime when using ThinLTO and /guard:cf. We probably don't want LLD LTO to set the "incremental linker compatible" assembler flag, since this has nothing to do with incremental linking, and we don't need to timestamp LTO temporary objects. Fixes PR36624. Reviewers: inglorion, espindola, majnemer Subscribers: mehdi_amini, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D44485 llvm-svn: 327557
* MC intel asm parser: Allow @ at the start of function names.Nico Weber2018-03-121-1/+4
| | | | | | | | Ports parts of r193000 to the intel parser. Fixes part of PR36676. https://reviews.llvm.org/D44359 llvm-svn: 327262
* [CodeView] Add line numbers for inlined call sitesReid Kleckner2018-01-181-0/+26
| | | | | | | | We did this for inline call site line tables, but we hadn't done it for regular function line tables yet. This patch copies that logic from encodeInlineLineTable. llvm-svn: 322905
* Reland "Emit Function IDs table for Control Flow Guard"Adrian McCarthy2018-01-091-0/+15
| | | | | | | | | | | | | | | | | Adds option /guard:cf to clang-cl and -cfguard to cc1 to emit function IDs of functions that have their address taken into a section named .gfids$y for compatibility with Microsoft's Control Flow Guard feature. The original patch didn't have the lit.local.cfg file that restricts the new test to x86, thus the new test was failing on the non-x86 bots. Differential Revision: https://reviews.llvm.org/D40531 The reverts r322008, which was a revert of r322005. This reverts commit a05b89f9aca70597dc79fe97bc49b50b51f525ba. llvm-svn: 322136
* Revert "Emit Function IDs table for Control Flow Guard"Adrian McCarthy2018-01-081-15/+0
| | | | | | | | | | The new test fails on the Hexagon bot. Reverting while I investigate. This reverts https://reviews.llvm.org/rL322005 This reverts commit b7e0026b4385180c378edc658ec91a39566f2942. llvm-svn: 322008
* Emit Function IDs table for Control Flow GuardAdrian McCarthy2018-01-081-0/+15
| | | | | | | | | | Adds option /guard:cf to clang-cl and -cfguard to cc1 to emit function IDs of functions that have their address taken into a section named .gfids$y for compatibility with Microsoft's Control Flow Guard feature. Differential Revision: https://reviews.llvm.org/D40531 llvm-svn: 322005
* [X86] Don't use NOPL when the assembler is passed an empty CPU string. ↵Craig Topper2017-12-181-1/+1
| | | | | | | | | | Update tests to force a CPU with NOPL Empty string should be equivalent to "generic" which doesn't allow NOPL. Force tests to use specificy 'pentiumpro' to guarantee NOPL. Fixes PR35686 llvm-svn: 321026
* [CodeGen] Unify MBB reference format in both MIR and debug outputFrancis Visoiu Mistrih2017-12-0414-18/+18
| | | | | | | | | | | | | | | | As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
* [CodeGen] Print register names in lowercase in both MIR and debug outputFrancis Visoiu Mistrih2017-11-281-1/+1
| | | | | | | | | | | As part of the unification of the debug format and the MIR format, always print registers as lowercase. * Only debug printing is affected. It now follows MIR. Differential Revision: https://reviews.llvm.org/D40417 llvm-svn: 319187
OpenPOWER on IntegriCloud