These MIPS specific symbols should be global because in general they can
have an arbitrary value. By default this value is a fixed offset from .got
section.

This patch adds more checks to the mips-gp-local.s test case but marks
it as XFAIL because LLD does not allow redefinition of absolute symbols
value by a linker script. This should be fixed by D27276.

Differential revision: https://reviews.llvm.org/D27524

llvm-svn: 289025

Most importantly, we need to hash the relocation model, otherwise we can
end up trying to link non-PIC object files into PIEs or DSOs.

Differential Revision: https://reviews.llvm.org/D27556

llvm-svn: 289024

to match other timeouts.

llvm-svn: 289023

Tagged parameter names with \a doxygen command to display them in italics.
Formatted comments to fit into 80 chars.

llvm-svn: 289022

tuple-like interpretation of decomposition declaration even if there is no
::value member. We already did this, anticipating this resolution, just update
comments and tweak a testcase.

llvm-svn: 289021

Thanks to George Rimar for pointing it out.

llvm-svn: 289020

We continue to support dynamic exception specifications in C++1z as an
extension, but produce an error-by-default warning when we encounter one. This
allows users to opt back into the feature with a warning flag, and implicitly
opts system headers back into the feature should they happen to use it.

There is one semantic change implied by P0003R5 but not implemented here:
violating a throw() exception specification should now call std::terminate
directly instead of calling std::unexpected(), but since P0003R5 also removes
std::unexpected() and std::set_unexpected, and the default unexpected handler
calls std::terminate(), a conforming C++1z program cannot tell that we are
still calling it. The upside of this strategy is perfect backwards
compatibility; the downside is that we don't get the more efficient 'noexcept'
codegen for 'throw()'.

llvm-svn: 289019

Allows darwin targets to provide additional definitions and
implementation specifc values for float.h

rdar://problem/21961491

llvm-svn: 289018

llvm-svn: 289017

of using the address of the all_image_infos struct.
<rdar://problem/29547847> 

llvm-svn: 289016

In the process, discovered a bug related to the use of an
uninitialized-pointer, and fixed as suggested by Enrico
in an lldb-dev mailing list thread.

llvm-svn: 289015

Appears to break on build bots. Reverting pending investigation.

llvm-svn: 289014

The relocations for `DIEEntry::EmitValue` were wrong for Win64
(emitting FK_Data_4 instead of FK_SecRel_4). This corrects that
oversight so that the DWARF data is correct in Win64 COFF files.

Fixes PR15393.

Patch by Jameson Nash <jameson@juliacomputing.com> based on a patch
by David Majnemer.

Differential Revision: https://reviews.llvm.org/D21731

llvm-svn: 289013

llvm-svn: 289012

Summary:
On actual Windows hosts :-) , this could report something other than the
fallback, with a non-zero minor/build number.

Reviewers: rnk, llvm-commits

Differential Revision: https://reviews.llvm.org/D27554

llvm-svn: 289011

The only tests we have for the DWARF parser are the tests that use llvm-dwarfdump and expect output from textual dumps.

More DWARF parser modification are coming in the next few weeks and I wanted to add tests that can verify that we can encode and decode all form types, as well as test some other basic DWARF APIs where we ask DIE objects for their children and siblings.

DwarfGenerator.cpp was added in the lib/CodeGen directory. This file contains the code necessary to easily create DWARF for tests:

dwarfgen::Generator DG;
Triple Triple("x86_64--");
bool success = DG.init(Triple, Version);
if (!success)
  return;
dwarfgen::CompileUnit &CU = DG.addCompileUnit();
dwarfgen::DIE CUDie = CU.getUnitDIE();

CUDie.addAttribute(DW_AT_name, DW_FORM_strp, "/tmp/main.c");
CUDie.addAttribute(DW_AT_language, DW_FORM_data2, DW_LANG_C);

dwarfgen::DIE SubprogramDie = CUDie.addChild(DW_TAG_subprogram);
SubprogramDie.addAttribute(DW_AT_name, DW_FORM_strp, "main");
SubprogramDie.addAttribute(DW_AT_low_pc, DW_FORM_addr, 0x1000U);
SubprogramDie.addAttribute(DW_AT_high_pc, DW_FORM_addr, 0x2000U);

dwarfgen::DIE IntDie = CUDie.addChild(DW_TAG_base_type);
IntDie.addAttribute(DW_AT_name, DW_FORM_strp, "int");
IntDie.addAttribute(DW_AT_encoding, DW_FORM_data1, DW_ATE_signed);
IntDie.addAttribute(DW_AT_byte_size, DW_FORM_data1, 4);

dwarfgen::DIE ArgcDie = SubprogramDie.addChild(DW_TAG_formal_parameter);
ArgcDie.addAttribute(DW_AT_name, DW_FORM_strp, "argc");
// ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref4, IntDie);
ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie);

StringRef FileBytes = DG.generate();
MemoryBufferRef FileBuffer(FileBytes, "dwarf");
auto Obj = object::ObjectFile::createObjectFile(FileBuffer);
EXPECT_TRUE((bool)Obj);
DWARFContextInMemory DwarfContext(*Obj.get());
This code is backed by the AsmPrinter code that emits DWARF for the actual compiler.

While adding unit tests it was discovered that DIEValue that used DIEEntry as their values had bugs where DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref8, and DW_FORM_ref_udata forms were not supported. These are all now supported. Added support for DW_FORM_string so we can emit inlined C strings.

Centralized the code to unique abbreviations into a new DIEAbbrevSet class and made both the dwarfgen::Generator and the llvm::DwarfFile classes use the new class.

Fixed comments in the llvm::DIE class so that the Offset is known to be the compile/type unit offset.

DIEInteger now supports more DW_FORM values.

There are also unit tests that cover:

Encoding and decoding all form types and values
Encoding and decoding all reference types (DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref8, DW_FORM_ref_udata, DW_FORM_ref_addr) including cross compile unit references with that go forward one compile unit and backward on compile unit.

Differential Revision: https://reviews.llvm.org/D27326

llvm-svn: 289010

llvm-svn: 289009

Replace @progbits in the section directive with %progbits, because "@" starts a comment on arm/thumb.
Use b.w branch instruction.
Use .thumb_function and .thumb_set for proper arm/thumb interwork. This way jumptable entry addresses on thumb have bit 0 set (correctly). This does not affect CFI check math, because the address of the jumptable start also has that bit set.

This does not work on thumbv5, because it does not support b.w, and the linker would not insert a veneer (trampoline?) to extend the range of b.n. We may need to do full-range plt-style jumptables on thumbv54, which are 12 bytes per entry. Another option is "push lr; bl; pop pc" (4 bytes) but that needs unwinding instructions, etc.

Differential Revision: https://reviews.llvm.org/D27499

llvm-svn: 289008

We are currently initializing Features via MAttrs.

llvm-svn: 289007

<rdar://problem/29191857>

llvm-svn: 289006

Currently -fstack-protector is on by default when using -ffreestanding.
Change the default behavior to have it off when using -ffreestanding.

rdar://problem/14089363

llvm-svn: 289005

llvm-svn: 289004

llvm-svn: 289003

llvm-svn: 289002

Since r287792 if we try to do that we will hit an assert.

llvm-svn: 289001

llvm-svn: 289000

Fixed DoConnectRemote issues where ProcessKDP wasn't switched over to use the version that needed a StringRef as the URL, and also updated all virtual functions to say "override" to make sure this doesn't happen again.

llvm-svn: 288999

Summary:
The MSVC toolchain and Clang driver combination currently uses a fairly complex
sequence of steps to determine the MS compatibility version to pass to cc1.
There is some oddness in this sequence currently, with some code which inspects
flags in the toolchain, and some code which inspects the triple and local
environment in the driver code.

This change is an attempt to consolidate most of this logic so that
Win32-specific code lives in MSVCToolChain.cpp. I'm not 100% happy with the
split, so any suggestions are welcome.

There are a few things you might want to watch for for specifically:

 - On all platforms, if MSVC compatibility flags are provided (and valid), use
   those.
 - The fallback sequence should be the same as before, but is now consolidated
   into MSVCToolChain::getMSVCVersion:
   - Otherwise, try to use the Triple.
   - Otherwise, on Windows, check the executable.
   - Otherwise, on Windows or with --fms-extensions, default to 18.
   - Otherwise, we can't determine the version.
 - MSVCToolChain::ComputeEffectiveTriple no longer calls the base
   ToolChain::ComputeEffectiveClangTriple. The only thing it would change for
   Windows the architecture, which we don't care about for the compatibility
   version.
    - I'm not sure whether this is philosophically correct (but it should
      be easy to add back to MSVCToolChain::getMSVCVersionFromTriple if not).
    - Previously, Tools.cpp just called getTriple() anyhow, so it doesn't look
      like the effective triple was always being used previously anyhow.

Reviewers: hans, compnerd, llvm-commits, rnk

Subscribers: amccarth

Differential Revision: https://reviews.llvm.org/D27477

llvm-svn: 288998

Summary:
This change adds more test cases for the default MSVC compatibility version:
 1. When -fms-extensions is supplied, but -fmsc-version and
    -fms-compatibility-version are not.
 2. With the target triple specifies an MSVC environment, but no other
    -fms* flags.

Reviewers: rnk, llvm-commits

Subscribers: hans, compnerd, amccarth

Differential Revision: https://reviews.llvm.org/D27498

llvm-svn: 288997

Obj is an instance of std::unique_ptr, so *Obj.get() is the same as *Obj.

llvm-svn: 288996

clang-format-diff sorted these #include's in the asciibetical order,
but they need to be in this order.

llvm-svn: 288995

llvm-svn: 288994

llvm-svn: 288993

Previously, we had different way to stringize SymbolBody and InputFile
to construct error messages. This patch defines overloaded function
toString() so that we don't need to memorize all these different
function names.

With that change, it is now easy to include demangled names in error
messages. Now, if there is a symbol name conflict, we'll print out
both mangled and demangled names.

llvm-svn: 288992

llvm-svn: 288991

This abstracts the code for emitting DWARF binary from the DWARFYAML types into reusable interfaces that could be used by ELF and COFF.

llvm-svn: 288990

[ADT, IR] Fix some Clang-tidy modernize-use-equals-delete and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 288989

Summary:
The test `XRay-aarch64-linux::patching-unpatching.cc` sometimes passes, sometimes fails on buildbots.
This patch disables test `patching-unpatching.cc` for AArch64 targets.

Reviewers: rengolin, dberris

Subscribers: llvm-commits, iid_iunknown, aemerson

Differential Revision: https://reviews.llvm.org/D27528

llvm-svn: 288988

The fix committed in r288851 doesn't cover all the cases.
In particular, if we have an instruction with side effects
which has a no non-dbg use not depending on the bits, we still
perform RAUW destroying the dbg.value's first argument.
Prevent metadata from being replaced here to avoid the issue.

Differential Revision:  https://reviews.llvm.org/D27534

llvm-svn: 288987

This makes the dwarf2yaml code separated and reusable allowing ELF and COFF to share implementations with MachO.

llvm-svn: 288986