2013-04-03 18:31:38 +00:00
|
|
|
set(LLVM_LINK_COMPONENTS
|
2023-04-17 00:17:45 +09:00
|
|
|
BinaryFormat
|
2016-05-05 00:34:33 +00:00
|
|
|
DebugInfoCodeView
|
2018-03-08 00:46:53 +00:00
|
|
|
DebugInfoDWARF
|
2019-01-17 17:55:47 +00:00
|
|
|
Demangle
|
2013-12-10 11:13:32 +00:00
|
|
|
Object
|
2021-07-12 10:14:42 -07:00
|
|
|
Option
|
2013-12-10 11:13:32 +00:00
|
|
|
Support
|
[Support] Move TargetParsers to new component
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
2022-12-20 10:24:02 +00:00
|
|
|
TargetParser
|
2013-12-10 11:13:32 +00:00
|
|
|
)
|
2012-03-01 01:36:50 +00:00
|
|
|
|
2021-07-12 10:14:42 -07:00
|
|
|
set(LLVM_TARGET_DEFINITIONS Opts.td)
|
|
|
|
|
tablegen(LLVM Opts.inc -gen-opt-parser-defs)
|
|
|
|
|
add_public_tablegen_target(ReadobjOptsTableGen)
|
|
|
|
|
|
2012-03-01 01:36:50 +00:00
|
|
|
add_llvm_tool(llvm-readobj
|
2014-06-04 15:47:15 +00:00
|
|
|
ARMWinEHPrinter.cpp
|
2013-04-03 18:31:38 +00:00
|
|
|
COFFDumper.cpp
|
2015-08-28 10:27:50 +00:00
|
|
|
COFFImportDumper.cpp
|
2013-04-03 18:31:38 +00:00
|
|
|
ELFDumper.cpp
|
2014-05-24 20:04:21 +00:00
|
|
|
llvm-readobj.cpp
|
|
|
|
|
MachODumper.cpp
|
|
|
|
|
ObjDumper.cpp
|
2017-01-30 23:30:52 +00:00
|
|
|
WasmDumper.cpp
|
2014-05-25 20:26:45 +00:00
|
|
|
Win64EHDumper.cpp
|
2017-09-20 18:33:35 +00:00
|
|
|
WindowsResourceDumper.cpp
|
2019-05-03 12:57:07 +00:00
|
|
|
XCOFFDumper.cpp
|
2022-12-13 16:56:08 +00:00
|
|
|
DEPENDS
|
|
|
|
|
ReadobjOptsTableGen
|
2022-10-06 05:16:13 +00:00
|
|
|
GENERATE_DRIVER
|
2012-03-01 01:36:50 +00:00
|
|
|
)
|
2017-07-19 02:09:37 +00:00
|
|
|
|
[CMake] Use LLVM own tools in extract_symbols.py
As for now, 'extract_symbols.py' can use several tools to extract
symbols from object files and libraries and to guess if the target is
32-bit Windows. The tools are being found via PATH, so in most cases,
they are just system tools. This approach has a number of limitations,
in particular:
* System tools may not be able to handle the target format in case of
cross-platform builds,
* They cannot read symbols from LLVM bitcode files, so the staged LTO
build with plugins is not supported,
* The auto-selected tools may be suboptimal (see D113557),
* Support for multiple tools for a single task increases the complexity
of the script code.
The patch proposes using LLVM's own tools to solve these issues.
Specifically, 'llvm-readobj' detects the target platform, and 'llvm-nm'
reads symbols from all supported formats, including bitcode files. The
tools can be built in Release mode for the host platform or overridden
using CMake settings 'LLVM_READOBJ' and 'LLVM_NM' respectively. The
implementation also supports using precompiled tools via
'LLVM_NATIVE_TOOL_DIR'.
Differential Revision: https://reviews.llvm.org/D149119
2023-04-21 20:01:10 -07:00
|
|
|
setup_host_tool(llvm-readobj LLVM_READOBJ llvm_readobj_exe llvm_readobj_target)
|
|
|
|
|
|
2017-07-19 02:09:37 +00:00
|
|
|
add_llvm_tool_symlink(llvm-readelf llvm-readobj)
|
2017-11-02 21:43:32 +00:00
|
|
|
|
|
|
|
|
if(LLVM_INSTALL_BINUTILS_SYMLINKS)
|
|
|
|
|
add_llvm_tool_symlink(readelf llvm-readobj)
|
|
|
|
|
endif()
|