Commit Graph

1505 Commits

Author SHA1 Message Date
serge-sans-paille 400b6c083f [NFC] Fix typo in error message 2020-02-24 18:22:05 +01:00
Francis Visoiu Mistrih 3f785212e9 Revert "[macho][NFC] Extract all CPU_(SUB_)TYPE logic to libObject"
This reverts commit 726c342ce2.

This breaks the windows bots with linker errors.
2020-02-20 10:51:25 -08:00
Francis Visoiu Mistrih 726c342ce2 [macho][NFC] Extract all CPU_(SUB_)TYPE logic to libObject
This moves all the logic of converting LLVM Triples to
MachO::CPU_(SUB_)TYPE from the specific target (Target)AsmBackend to
more convenient functions in libObject.

This also gets rid of the separate two X86AsmBackend classes.

Differential Revision: https://reviews.llvm.org/D74808
2020-02-20 10:28:07 -08:00
Sam Clegg bd4812776b [WebAssembly] Use llvm::Optional to store optional symbol attributes. NFC.
The changes the in-memory representation of wasm symbols such that their
optional ImportName and ImportModule use llvm::Optional.

ImportName is set whenever WASM_SYMBOL_EXPLICIT_NAME flag is set.
ImportModule (for imports) is currently always set since it defaults to
"env".

In the future we can possibly extent to binary format distingish
import which have explit module names.

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D74109
2020-02-19 17:25:33 -08:00
serge-sans-paille 498a6136a2 Prevent gcc from issuing a warning upon coffnamecpy
This is a follow up to d1262a6e9, more explicit to cope with GCC smartness.

Differential Revision: https://reviews.llvm.org/D74666
2020-02-18 16:13:59 +01:00
Fangrui Song 6d2d589b06 [MC] De-capitalize another set of MCStreamer::Emit* functions
Emit{ValueTo,Code}Alignment Emit{DTP,TP,GP}* EmitSymbolValue etc
2020-02-14 19:26:52 -08:00
Fangrui Song a55daa1461 [MC] De-capitalize some MCStreamer::Emit* functions 2020-02-14 19:11:53 -08:00
Fangrui Song bcd24b2d43 [AsmPrinter][MCStreamer] De-capitalize EmitInstruction and EmitCFI* 2020-02-13 22:08:55 -08:00
Bill Wendling c55cf4afa9 Revert "Remove redundant "std::move"s in return statements"
The build failed with

  error: call to deleted constructor of 'llvm::Error'

errors.

This reverts commit 1c2241a793.
2020-02-10 07:07:40 -08:00
Bill Wendling 1c2241a793 Remove redundant "std::move"s in return statements 2020-02-10 06:39:44 -08:00
jasonliu 3bbe7a681e [XCOFF][AIX] Support basic relocation type on AIX
Summary:

This patch intends to support three most common relocation type
on AIX: R_POS, R_TOC, R_RBR.
These three relocation type will be needed for object file generation
on AIX for small code model.
We will have follow up patches to bring relocation support for
large code model on AIX.

Reviewers: hubert.reinterpretcast, daltenty, DiggerLin

Differential Revision: https://reviews.llvm.org/D72027
2020-01-30 15:59:09 +00:00
Nate Voorhies a40b3e3b61 [NFC] Fix unused variable warning.
Reviewers: dschuff

Reviewed By: dschuff

Subscribers: hiraditya, aheejin, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D73591
2020-01-28 17:19:23 -08:00
Benjamin Kramer a9bc7b83a4 Another round of GCC5 fixes. 2020-01-29 02:09:24 +01:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
Derek Schuff da6a896e6b [WebAssembly] Add WebAssembly support to llvm-symbolizer
The only thing missing for basic llvm-symbolizer support is the ability on
lib/Object to get a wasm symbol's section ID, which allows sorting and
computation of the symbols' sizes.

Also, when the WasmAsmParser switches sections on new functions, also add the
section to the list of Dwarf sections if Dwarf is being generated for assembly;
this allows writing of simple tests.

Reviewers: sbc100, jhenderson, aardappel

Differential Revision: https://reviews.llvm.org/D73246
2020-01-28 09:55:38 -08:00
Alex Richardson 894f742acb [MIPS][ELF] Use PC-relative relocations in .eh_frame when possible
When compiling position-independent executables, we now use
DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a
64-bit PC-relative ELF relocation so we cannot use sdata8 for the large
code model case. When using the large code model, we fall back to the
previous behaviour of generating absolute relocations.

With this change clang-generated .o files can be linked by LLD without
having to pass -Wl,-z,notext (which creates text relocations).
This is simpler than the approach used by ld.bfd, which rewrites the
.eh_frame section to convert absolute relocations into relative references.

I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations
for MIPS ouput at some point. However, I also checked that recent ld.bfd
can process the clang-generated .o files so this no longer seems true.

Reviewed By: atanasyan
Differential Revision: https://reviews.llvm.org/D72228
2020-01-13 14:14:03 +00:00
Georgii Rymar 301cb91428 [llvm-readobj] - Remove an excessive helper for printing dynamic tags.
This removes the `getTypeString` from readeobj source because it
almost duplicates the existent method: `ELFFile<ELFT>::getDynamicTagAsString`.

Side effect: now it prints "<unknown:>0xHEXVALUE" instead of "(unknown)" for unknown values.
llvm-readelf before this patch printed:

```
0x0000000012345678 (unknown) 0x8765432187654321
0x000000006abcdef0 (unknown) 0x9988776655443322
0x0000000076543210 (unknown) 0x5555666677778888
```

and now it prints:

```
0x0000000012345678 (<unknown:>0x12345678) 0x8765432187654321
0x000000006abcdef0 (<unknown:>0x6abcdef0) 0x9988776655443322
0x0000000076543210 (<unknown:>0x76543210) 0x5555666677778888
```

GNU reaedlf prints different thing:

```
0x0000000012345678 (<unknown>: 12345678) 0x8765432187654321
0x000000006abcdef0 (Operating System specific: 6abcdef0) 0x9988776655443322
0x0000000076543210 (Processor Specific: 76543210) 0x5555666677778888
```

I am not sure we want to follow GNU here. Even if we do, it should be separate
patch probably. The new output looks better and closer to GNU anyways,
and the code is a bit simpler.

Differential revision: https://reviews.llvm.org/D71835
2019-12-24 11:55:45 +03:00
Sam Clegg 881d877846 [WebAssembly] Add new `export_name` clang attribute for controlling wasm 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
2019-12-11 11:54:57 -08:00
Luís Marques 7bf721e59c [Object][RISCV] Resolve R_RISCV_32_PCREL
Summary: Add support for resolving `R_RISCV_32_PCREL` relocations. Those aren't
actually resolved AFAIK, but support is still needed to avoid llvm-dwarfdump
errors. The use of these relocations was introduced in D66419 but the
corresponding resolving wasn't added then. The test adds a check that should
catch future unresolved relocations.

Reviewers: asb, lenary
Reviewed By: asb
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70204
2019-11-21 23:34:05 +00:00
Luís Marques b8b57087d3 [Object][RISCV] Fix R_RISCV_SET6 and R_RISCV_SUB6 relocations resolution
Summary: These relocations had a suspicious resolution logic, given their name.
This patch makes the resolution match the LLD one, which makes more sense.

Reviewers: asb, lenary, HsiangKai, jrtc27
Reviewed By: HsiangKai
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70396
2019-11-21 22:54:10 +00:00
Tom Stellard ab411801b8 [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"
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
2019-11-21 10:48:08 -08:00
diggerlin ea13683f3d The patch is the compiler error specific on the compile error on CMVC
SUMMARY:

CMVC has a compiler error on the
const uint64_t OffsetToRaw = is64Bit()
                                   ? toSection64(Sec)->FileOffsetToRawData
                                   : toSection32(Sec)->FileOffsetToRawData;

while  gcc  compiler do not have the problem.
I have to change the code to

  uint64_t OffsetToRaw;
  if (is64Bit())
    OffsetToRaw = toSection64(Sec)->FileOffsetToRawData;
  else
    OffsetToRaw = toSection32(Sec)->FileOffsetToRawData;

Reviewers: Sean Fertile
Subscribers: rupprecht, seiyai,hiraditya

Differential Revision: https://reviews.llvm.org/D70255
2019-11-19 15:17:56 -05:00
diggerlin b91f798fde implement printing out raw section data of xcoff objectfile for llvm-objdump
SUMMARY:
implement printing out raw section data of xcoff objectfile for llvm-objdump
and option -D --disassemble-all option for llvm-objdump

Reviewers: Sean Fertile
Subscribers: rupprecht, seiyai,hiraditya

Differential Revision: https://reviews.llvm.org/D70255
2019-11-19 13:31:00 -05:00
Pavel Labath c0fc29c468 Add operator<< for object::SectionedAddress
The main motivation for this is better failure messages in unit tests.

Split off from D70394.
2019-11-19 10:34:30 +01:00
Leonard Chan 66b6b92765 Revert "implement printing out raw section data of xcoff objectfile for llvm-objdump"
This reverts commit 8f8a9f3437.

Reverting since this patch seems to break a lot of llvm buildbots.
2019-11-18 20:05:57 -08:00
Daniel Sanders 1791901787 [macho] Allow CPUSubtype to contribute to architecture identification
Summary:
Sometimes the CPUSubtype determines the Triple::ArchType that must be used.
Add the subtype to the API's to allow targets that need this to correctly
identify the contents of the binary.

Reviewers: pete

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D70345
2019-11-18 12:57:39 -08:00
diggerlin 8f8a9f3437 implement printing out raw section data of xcoff objectfile for llvm-objdump
SUMMARY:
implement printing out raw section data of xcoff objectfile for llvm-objdump
and option -D --disassemble-all option for llvm-objdump

Reviewers: Sean Fertile
Subscribers: rupprecht, seiyai,hiraditya

Differential Revision: https://reviews.llvm.org/D70255
2019-11-18 15:24:55 -05:00
Reid Kleckner 2cb3bfe975 Revert "[XCOFF] Fix link errors from explicit template instantiation"
This reverts commit c989993ba1.

maskray already fixed the explicit instantiation definition in the .cpp
file, and these extern template declarations seem to be causing
warnings that I don't understand.
2019-11-07 09:39:13 -08:00
Reid Kleckner c989993ba1 [XCOFF] Fix link errors from explicit template instantiation
I happen to be using clang-cl+lld-link locally, and I get these link
errors:

lld-link: error: undefined symbol: public: unsigned short __cdecl llvm::object::XCOFFSectionHeader<struct llvm::object::XCOFFSectionHeader64>::getSectionType(void) const
>>> referenced by C:\src\llvm-project\llvm\tools\llvm-readobj\XCOFFDumper.cpp:106
>>>               tools\llvm-readobj\CMakeFiles\llvm-readobj.dir\XCOFFDumper.cpp.obj:(public: virtual void __cdecl `anonymous namespace'::XCOFFDumper::printSectionHeaders(void))

I suspect this is because the explicit template instaniation appears
before the inline method definitions in the .cpp file, so they aren't
available at the point of instantiation. Move the explicit instantiation
later.

Also, forward declare the explicit instantiation for good measure.
2019-11-07 09:29:48 -08:00
Fangrui Song f8622543ad [XCOFF] Move explicit instantions after member function definitions to fix clang builds 2019-11-07 09:25:55 -08:00
diggerlin c63c1a72da Using crtp to refactor the xcoff section header
SUMMARY:
According to https://reviews.llvm.org/D68575#inline-617586, Create a NFC patch for it.

Using crtp to refactor the xcoff section header
Move the define of SectionFlagsReservedMask and SectionFlagsTypeMask from XCOFFDumper.cpp to XCOFFObjectFile.h

Reviewers: hubert.reinterpretcast,jasonliu
Subscribers: rupprecht, seiyai,hiraditya

Differential Revision: https://reviews.llvm.org/D69131
2019-11-07 11:51:34 -05:00
Mirko Brkusanin 4b63ca1379 [Mips] Use appropriate private label prefix based on Mips ABI
MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64
regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo
we can find out Mips ABI and pick appropriate prefix.

Tags: #llvm, #clang, #lldb

Differential Revision: https://reviews.llvm.org/D66795
2019-10-23 12:24:35 +02:00
George Rimar 2bf01dcbaa [llvm/Object] - Make ELFObjectFile::getRelocatedSection return Expected<section_iterator>
It returns just a section_iterator currently and have a report_fatal_error call inside.
This change adds a way to return errors and handle them on caller sides.

The patch also changes/improves current users and adds test cases.

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

llvm-svn: 375408
2019-10-21 11:06:38 +00:00
Thomas Lively 393d0f799f [WebAssembly] Allow multivalue signatures in object files
Summary:
Also changes the wasm YAML format to reflect the possibility of having
multiple return types and to put the returns after the params for
consistency with the binary encoding.

Reviewers: aheejin, sbc100

Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, arphaman, rupprecht, llvm-commits

Tags: #llvm

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

llvm-svn: 375283
2019-10-18 20:27:30 +00:00
Simon Pilgrim da40d4e4e1 Fix MSVC "result of 32-bit shift implicitly converted to 64 bits" warnings. NFCI.
llvm-svn: 375213
2019-10-18 09:59:31 +00:00
Digger Lin 34d4bff3d6 [XCOFF]implement parsing relocation information for 32-bit xcoff object file
Summary:
    Parsing the relocation entry information for 32-bit xcoff object file
including deal with the relocation overflow.

Reviewers: hubert.reinterpretcast, jasonliu, sfertile, xingxue.

Subscribers: hiraditya, rupprecht, seiya

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

llvm-svn: 374946
2019-10-15 20:42:11 +00:00
Digger Lin 52d2a567b5 revert git test commit
llvm-svn: 374898
2019-10-15 14:44:06 +00:00
Digger Lin defaea0b6c a test commit access
llvm-svn: 374897
2019-10-15 14:39:29 +00:00
Pavel Labath 6e0b1ce48e Object/minidump: Add support for the MemoryInfoList stream
Summary:
This patch adds the definitions of the constants and structures
necessary to interpret the MemoryInfoList minidump stream, as well as
the object::MinidumpFile interface to access the stream.

While the code is fairly simple, there is one important deviation from
the other minidump streams, which is worth calling out explicitly.
Unlike other "List" streams, the size of the records inside
MemoryInfoList stream is not known statically. Instead it is described
in the stream header. This makes it impossible to return
ArrayRef<MemoryInfo> from the accessor method, as it is done with other
streams. Instead, I create an iterator class, which can be parameterized
by the runtime size of the structure, and return
iterator_range<iterator> instead.

Reviewers: amccarth, jhenderson, clayborg

Subscribers: JosephTremoulet, zturner, markmentovai, lldb-commits, llvm-commits

Tags: #llvm

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

llvm-svn: 374051
2019-10-08 14:15:32 +00:00
Simon Pilgrim bc9a1b37b9 ObjectFile makeTriple - silence static analyzer dyn_cast<COFFObjectFile> null dereference warning. NFCI.
The static analyzer is warning about a potential null dereference, but we should be able to use cast<COFFObjectFile> directly and if not assert will fire for us.

llvm-svn: 373324
2019-10-01 11:25:17 +00:00
Guillaume Chatelet 18f805a7ea [Alignment][NFC] Remove unneeded llvm:: scoping on Align types
llvm-svn: 373081
2019-09-27 12:54:21 +00:00
Huihui Zhang a18b00c8d5 [NFC] Add { } to silence compiler warning [-Wmissing-braces].
/local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/lib/Object/MachOObjectFile.cpp:2731:7: warning: suggest braces around initialization of subobject [-Wmissing-braces]
      "i386",   "x86_64", "x86_64h",  "armv4t",  "arm",    "armv5e",
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      {
1 warning generated.

/local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp:355:46: warning: suggest braces around initialization of subobject [-Wmissing-braces]
    return addMappingFromTable<1>(MI, MRI, { 0 }, Table);
                                             ^
                                             {}
1 warning generated.

/local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/tools/llvm-objcopy/ELF/Object.cpp:400:57: warning: suggest braces around initialization of subobject [-Wmissing-braces]
static constexpr std::array<uint8_t, 4> ZlibGnuMagic = {'Z', 'L', 'I', 'B'};
                                                        ^~~~~~~~~~~~~~~~~~
                                                        {                 }
1 warning generated.

llvm-svn: 372811
2019-09-25 04:40:07 +00:00
Artur Pilipenko 3e6590c451 Support for 64-bit PC-relative relocations for X86_64
ELF files generated for X86_64 targets may contain 64-bit PC-relative 
relocations. For instance, an exception handler table entry contains the start 
of exception-throwing frame relative to the start of exception handler. As these 
two labels belong to different sections, their difference and so the relocation 
is 64-bit.

An attempt to parse such file, i.e. in DWARFContext::create, results in "failed 
to compute relocation" error.

This fix adds support for such relocations to RelocationResolver.cpp.

Reviewed By: MaskRay

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

Patch by Oleg Pliss (Oleg.Pliss@azul.com)

llvm-svn: 372447
2019-09-21 01:37:14 +00:00
Cyndy Ishida 81669d5ead [TextAPI] Arch&Platform to Target
Summary:
This is a patch for updating TextAPI/Macho to read in targets as opposed to arch/platform.
This is because in previous versions tbd files only supported a single platform but that is no longer the case,
so, now its tracked by unique triples.
This precedes a seperate patch that will add  the TBD-v4 format

Reviewers: ributzka, steven_wu, plotfi, compnerd, smeenai

Reviewed By: ributzka

Subscribers: mgorny, hiraditya, dexonsmith, llvm-commits

Tags: #llvm

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

llvm-svn: 372396
2019-09-20 14:32:34 +00:00
Fangrui Song a5db9ee71f [Object] Uncapitalize an error message
Test case will be added by my next commit.

llvm-svn: 372369
2019-09-20 04:40:38 +00:00
Alexander Shaposhnikov 4fd11c1e45 [Object] Extend MachOUniversalBinary::getObjectForArch
Make the method MachOUniversalBinary::getObjectForArch return MachOUniversalBinary::ObjectForArch
and add helper methods MachOUniversalBinary::getMachOObjectForArch, MachOUniversalBinary::getArchiveForArch
for those who explicitly expect to get a MachOObjectFile or an Archive.

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

Test plan: make check-all

llvm-svn: 372278
2019-09-19 00:02:12 +00:00
Eli Friedman ddf5e86c22 [ARM] VFPv2 only supports 16 D registers.
r361845 changed the way we handle "D16" vs. "D32" targets; there used to
be a negative "d16" which removed instructions from the instruction set,
and now there's a "d32" feature which adds instructions to the
instruction set.  This is good, but there was an oversight in the
implementation: the behavior of VFPv2 was changed.  In particular, the
"vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only
supports 16 D registers.

In practice, this means if you specify -mfpu=vfpv2, the compiler will
generate illegal instructions.

This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and
"vfp2sp" so they don't imply "d32".

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

llvm-svn: 372186
2019-09-17 21:42:38 +00:00
Guillaume Chatelet af11cc7eb5 [Alignment] Move OffsetToAlignment to Alignment.h
Summary:
This is patch is part of a series to introduce an Alignment type.
See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html
See this patch for the introduction of the type: https://reviews.llvm.org/D64790

Reviewers: courbet, JDevlieghere, alexshap, rupprecht, jhenderson

Subscribers: sdardis, nemanjai, hiraditya, kbarton, jakehehrlich, jrtc27, MaskRay, atanasyan, jsji, seiya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 371742
2019-09-12 15:20:36 +00:00
Cyndy Ishida bc40836a43 Revert [llvm-nm] Add tapi file support
This reverts r371576 (git commit f88f46358d)

llvm-svn: 371676
2019-09-11 21:35:28 +00:00
Cyndy Ishida f88f46358d [llvm-nm] Add tapi file support
Summary:
This commit is the final one for adding tapi support to the llvm-nm implementation.
This commit also has accompanying tests the additions to lib/Object

Reviewers: ributzka, steven_wu

Reviewed By: ributzka

Subscribers: hiraditya, plotfi, dexonsmith, rupprecht, llvm-commits

Tags: #llvm

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

llvm-svn: 371576
2019-09-11 00:00:53 +00:00