2017-02-11 00:27:28 +00:00
|
|
|
//===- MCAsmInfoCOFF.cpp - COFF asm properties ----------------------------===//
|
2009-07-27 16:45:59 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2009-07-27 16:45:59 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file defines target asm properties related what form asm statements
|
|
|
|
// should take in general on COFF-based targets
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2009-08-22 20:48:53 +00:00
|
|
|
#include "llvm/MC/MCAsmInfoCOFF.h"
|
2017-02-11 00:27:28 +00:00
|
|
|
#include "llvm/MC/MCDirectives.h"
|
|
|
|
|
2009-07-27 16:45:59 +00:00
|
|
|
using namespace llvm;
|
|
|
|
|
2017-02-11 00:27:28 +00:00
|
|
|
void MCAsmInfoCOFF::anchor() {}
|
2011-12-20 02:50:00 +00:00
|
|
|
|
2010-01-20 06:34:14 +00:00
|
|
|
MCAsmInfoCOFF::MCAsmInfoCOFF() {
|
2012-09-07 21:08:01 +00:00
|
|
|
// MingW 4.5 and later support .comm with log2 alignment, but .lcomm uses byte
|
|
|
|
// alignment.
|
|
|
|
COMMDirectiveAlignmentIsInBytes = false;
|
|
|
|
LCOMMDirectiveAlignmentType = LCOMM::ByteAlignment;
|
2009-07-27 16:45:59 +00:00
|
|
|
HasDotTypeDotSizeDirective = false;
|
[MC] Enable .file support on COFF and diagnose it on unsupported targets
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
2018-12-21 23:35:48 +00:00
|
|
|
HasSingleParameterDotFile = true;
|
2009-07-27 16:45:59 +00:00
|
|
|
WeakRefDirective = "\t.weak\t";
|
2013-12-02 23:04:51 +00:00
|
|
|
HasLinkOnceDirective = true;
|
2012-05-11 01:41:30 +00:00
|
|
|
|
2010-01-23 06:53:23 +00:00
|
|
|
// Doesn't support visibility:
|
2011-09-23 00:13:02 +00:00
|
|
|
HiddenVisibilityAttr = HiddenDeclarationVisibilityAttr = MCSA_Invalid;
|
|
|
|
ProtectedVisibilityAttr = MCSA_Invalid;
|
2009-07-27 16:45:59 +00:00
|
|
|
|
|
|
|
// Set up DWARF directives
|
|
|
|
SupportsDebugInformation = true;
|
2013-04-22 22:49:11 +00:00
|
|
|
NeedsDwarfSectionOffsetDirective = true;
|
2014-02-13 14:44:26 +00:00
|
|
|
|
|
|
|
UseIntegratedAssembler = true;
|
2015-04-28 01:37:11 +00:00
|
|
|
|
2015-11-11 00:51:36 +00:00
|
|
|
// At least MSVC inline-asm does AShr.
|
2015-04-28 01:37:11 +00:00
|
|
|
UseLogicalShr = false;
|
[mingw] Fix GCC ABI compatibility for comdat things
Summary:
GCC and the binutils COFF linker do comdats differently from MSVC.
If we want to be ABI compatible, we have to do what they do, which is to
emit unique section names like ".text$_Z3foov" instead of short section
names like ".text". Otherwise, the binutils linker gets confused and
reports multiple definition errors when two object files from GCC and
Clang containing the same inline function are linked together.
The best description of the issue is probably at
https://github.com/Alexpux/MINGW-packages/issues/1677, we don't seem to
have a good one in our tracker.
I fixed up the .pdata and .xdata sections needed everywhere other than
32-bit x86. GCC doesn't use associative comdats for those, it appears to
rely on the section name.
Reviewers: smeenai, compnerd, mstorsjo, martell, mati865
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D48402
llvm-svn: 335286
2018-06-21 20:27:38 +00:00
|
|
|
|
|
|
|
// If this is a COFF target, assume that it supports associative comdats. It's
|
|
|
|
// part of the spec.
|
|
|
|
HasCOFFAssociativeComdats = true;
|
2018-07-26 10:48:20 +00:00
|
|
|
|
|
|
|
// We can generate constants in comdat sections that can be shared,
|
|
|
|
// but in order not to create null typed symbols, we actually need to
|
|
|
|
// make them global symbols as well.
|
|
|
|
HasCOFFComdatConstants = true;
|
2009-07-27 16:45:59 +00:00
|
|
|
}
|
2011-11-29 18:00:06 +00:00
|
|
|
|
2017-02-11 00:27:28 +00:00
|
|
|
void MCAsmInfoMicrosoft::anchor() {}
|
2011-11-29 18:00:06 +00:00
|
|
|
|
2017-02-11 00:27:28 +00:00
|
|
|
MCAsmInfoMicrosoft::MCAsmInfoMicrosoft() = default;
|
2011-12-20 02:50:00 +00:00
|
|
|
|
2017-02-11 00:27:28 +00:00
|
|
|
void MCAsmInfoGNUCOFF::anchor() {}
|
2011-11-29 18:00:06 +00:00
|
|
|
|
[mingw] Fix GCC ABI compatibility for comdat things
Summary:
GCC and the binutils COFF linker do comdats differently from MSVC.
If we want to be ABI compatible, we have to do what they do, which is to
emit unique section names like ".text$_Z3foov" instead of short section
names like ".text". Otherwise, the binutils linker gets confused and
reports multiple definition errors when two object files from GCC and
Clang containing the same inline function are linked together.
The best description of the issue is probably at
https://github.com/Alexpux/MINGW-packages/issues/1677, we don't seem to
have a good one in our tracker.
I fixed up the .pdata and .xdata sections needed everywhere other than
32-bit x86. GCC doesn't use associative comdats for those, it appears to
rely on the section name.
Reviewers: smeenai, compnerd, mstorsjo, martell, mati865
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D48402
llvm-svn: 335286
2018-06-21 20:27:38 +00:00
|
|
|
MCAsmInfoGNUCOFF::MCAsmInfoGNUCOFF() {
|
|
|
|
// If this is a GNU environment (mingw or cygwin), don't use associative
|
|
|
|
// comdats for jump tables, unwind information, and other data associated with
|
|
|
|
// a function.
|
|
|
|
HasCOFFAssociativeComdats = false;
|
2018-07-26 10:48:20 +00:00
|
|
|
|
|
|
|
// We don't create constants in comdat sections for MinGW.
|
|
|
|
HasCOFFComdatConstants = false;
|
[mingw] Fix GCC ABI compatibility for comdat things
Summary:
GCC and the binutils COFF linker do comdats differently from MSVC.
If we want to be ABI compatible, we have to do what they do, which is to
emit unique section names like ".text$_Z3foov" instead of short section
names like ".text". Otherwise, the binutils linker gets confused and
reports multiple definition errors when two object files from GCC and
Clang containing the same inline function are linked together.
The best description of the issue is probably at
https://github.com/Alexpux/MINGW-packages/issues/1677, we don't seem to
have a good one in our tracker.
I fixed up the .pdata and .xdata sections needed everywhere other than
32-bit x86. GCC doesn't use associative comdats for those, it appears to
rely on the section name.
Reviewers: smeenai, compnerd, mstorsjo, martell, mati865
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D48402
llvm-svn: 335286
2018-06-21 20:27:38 +00:00
|
|
|
}
|