Both Swift & LLD use TextAPI reader/writer apis to interface with TBD
files. Add doc strings to document what each API does. Also, add
shortcut APIs for validating input is a TBD file.
This reduces the differences between downstream and how tapi calls into
these APIs.
TBD files now record minimum deplyoment versions and tapi interfaces
with apple system linker by a packed version encoding. Support mapping
between that and `VersionTuple`s.
This adds a new optional flag sim_support which is the same as
MH_SIM_SUPPORT in the MachO header.
Reviewed By: ributzka
Differential Revision: https://reviews.llvm.org/D157433
The minOS version is recorded in tbd-v5 so the linker can report
diagnostics when a library and client are misconfigured.
Dylibs should always have a minOS recorded, but in was not recorded in
previous TBD versions. To accommodate the format transition, treat
unrecorded minOS versions as 0.
Reviewed By: zixuw
Differential Revision: https://reviews.llvm.org/D156487
* Expand understood `FileType`s that InterfaceFile class can represent.
* Add `hasTarget` function.
* Cleanup symbol `<` comparator to account for SymbolSet operations.
InterfaceFile is the in-memory representation for tbd files. Add APIs to
merge, extract, remove, and inline reexported libraries.
Reviewed By: zixuw
Differential Revision: https://reviews.llvm.org/D153398
UUID's & `installapi` flag are no longer useful in recent apple linker/tapi.
The reason for removing them is that these are attributes that record
how a library was built but not really about the library itself. TBD
files now only track information this is important as link time
dependencies.
Reviewed By: ributzka
Differential Revision: https://reviews.llvm.org/D149861
SymbolSet is a structure that acts as a simple container class for exported symbols that
belong to a library interface. It allows tapi to decouple the globals
from the other library attributes. It's uniqued by symbol name and `kind`, which all contain their assigned target triples.
Reviewed By: zixuw
Differential Revision: https://reviews.llvm.org/D149860
Sometimes the clang driver will receive a target triple where the
deployment version is too low to support the platform + arch. In those
cases, the compiler upgrades the final minOS which is what gets recorded
ultimately by the linker in LC_BUILD_VERSION. TextAPI should also reuse
this logic for capturing minOS in recorded TBDv5 files.
Reviewed By: ributzka
Differential Revision: https://reviews.llvm.org/D145690
This includes handling of new attributes for symbols & rpath.
In the event that an older format file is compared to tbd_v5, ignore these new attributes.
Reviewed By: ributzka
Differential Revision: https://reviews.llvm.org/D144529
* Always print out maccatalyst in format
* Traverse symbols via InterfaceFile symbol APIs
* Properly track addition of flags.
Reviewed By: ributzka
Differential Revision: https://reviews.llvm.org/D144428
Create writer for new JSON format.
The new JSON format allows practically all attributes to be defined per
target in a universal library however the internal representation only
allows one for the time being. For now the write will always write those
attributes as default available for all targets (install name,
compatability & current version, swift abi, flags e.g. flatnamepace &
app exenstion safety)
rdar://102076911
Reviewed By: ributzka
Differential Revision: https://reviews.llvm.org/D144339
Create writer for new JSON format.
The new JSON format allows practically all attributes to be defined per
target in a universal library however the internal representation only
allows one for the time being. For now the write will always write those
attributes as default available for all targets (install name,
compatability & current version, swift abi, flags e.g. flatnamepace &
app exenstion safety)
rdar://102076911
Reviewed By: ributzka
Differential Revision: https://reviews.llvm.org/D144339
* Deployment Versions for targets
* Run Search Paths
* Text vs Data Segment attributes to symbols
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D144158
Introduce initial reader for TBDv5 which is in JSON. This captures all
the currently understood fields within the internal structure
`InterfaceFile`.
New fields will be followed up in future PRs.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D144156
This reverts commit b861b1225380175a5a724e2a677754f5f74e5b0d.
This reverts commit 4be17641b05df1e63fa8e069af92676f1246eb83.
This patch wont build on some compilers on buildbot.
[TextAPI] Implement TBDv5 Reader
Introduce initial reader for TBDv5 which is in JSON. This captures all
the currently understood fields within the internal structure
`InterfaceFile`.
New fields & follow up tests will be followed up in future PRs.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D144156
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
Based on the output of iwyu. A full rebuild of llvm-project doesn't exhibit any
significant false dependencies.
The impact on preprocessed output is larger than expected, given the small
amount of changes
$ clang++ -E -Iinclude -I../llvm/include ../llvm/lib/TextAPI/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l
before: 635319
After: 643716
Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup
The PlatformKind/PlatformType enums contain the same information, which requires
them to be kept in-sync. This commit changes over to PlatformType as the sole
source of truth, which allows the removal of the redundant PlatformKind.
The majority of the changes were in LLD and TextAPI.
Reviewed By: cishida
Differential Revision: https://reviews.llvm.org/D117163
This is relanding commit d1d36f7ad2ae82bea8a6fcc40d6c42a72e21f096 .
This patch additionally addresses failures found in buildbots due to unstable build ordering & post review comments.
This patch introduces a new tool, llvm-tapi-diff, that compares and returns the diff of two TBD files.
Reviewed By: ributzka, JDevlieghere
Differential Revision: https://reviews.llvm.org/D101835
This is relanding commit d1d36f7ad2ae82bea8a6fcc40d6c42a72e21f096 .
This patch additionally addresses failures found in buildbots & post review comments.
This patch introduces a new tool, llvm-tapi-diff, that compares and returns the diff of two TBD files.
Reviewed By: ributzka, JDevlieghere
Differential Revision: https://reviews.llvm.org/D101835
This patch introduces a new tool, llvm-tapi-diff, that compares and returns the diff of two TBD files.
Reviewed By: ributzka, JDevlieghere
Differential Revision: https://reviews.llvm.org/D101835
TextAPI/ELF has moved out into InterfaceStubs, so theres no longer a
need to seperate out TextAPI between formats.
Reviewed By: ributzka, int3, #lld-macho
Differential Revision: https://reviews.llvm.org/D99811
Currently, it was delibrately impleneted to not handle this case, but as it has turnt out, we need this feature.
The concrete use case is
`System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa` reexports
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit , which then rexports
/System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation
The current implemention uses a global currentTopLevelTapi, which is not reset until it finishes loading the whole tree.
This is a problem because if the top-level is set to Cocoa, then when we get to UIFoundation, it will try to find UIFoundation in the current top level, which is Cocoa and will not find it.
The right thing should be:
- When loading a library from a TBD file, re-exports need to be looked up in the auxiliary documents within the same TBD.
- When loading from an actual dylib, no additional TBD documents need to be examined.
- In no case does a re-export mentioned in one TBD file need to be looked up in a document in an auxiliary document from a different TBD file
Differential Revision: https://reviews.llvm.org/D97438
This patch adds functionality to compare for the equality between `InterfaceFile`s based on attributes specific to linking.
Reviewed By: cishida, steven_wu
Differential Revision: https://reviews.llvm.org/D96629
No longer rely on an external tool to build the llvm component layout.
Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.
These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.
Differential Revision: https://reviews.llvm.org/D90848
