Until now, these have been hardcoded as a downstream patches in lld. Add
them to the driver so that the private patches can be removed.
PS5 only. On PS4, the equivalent hardcoded configuration will remain in
the proprietary linker.
SIE tracker: TOOLCHAIN-16704
Until now, this has been hardcoded as a downstream patch in lld. Add it
to the driver so that the private patch can be removed.
PS5 only. On PS4, the equivalent hardcoded configuration will remain in
the proprietary linker.
SIE tracker: TOOLCHAIN-16704
Until now, these options have been hardcoded as downstream patches in
lld. Add them to the driver so that the private patches can be removed.
PS5 only. On PS4, the proprietary linker will continue to perform the
equivalent behaviours itself.
SIE tracker: TOOLCHAIN-16704
Until now, these options have been hardcoded as downstream patches in
LLD. Add them to the driver so that the private patches can be removed.
PS5 only. The implementation of these behaviours will remain in the
proprietary linker on PS4.
SIE tracker: TOOLCHAIN-16704
The proprietary PS4 linker implicitly adds `=/target/lib` and `.` as
library search paths. This behaviour was added to the PS5 linker via a
downstream patch in LLD. This really belongs in the driver, instead.
This change adds the driver behaviour to allow removal of the downstream
patch in LLD.
There are no plans to update the PS4 linker behaviour in the analogous
way, so do not pass the same search paths to the PS4 linker.
SIE tracker: TOOLCHAIN-16704
The following discrepancies concerning `-isysroot` and `--sysroot`
motivated this change:
- The SDK directory can be specified via `-isysroot`, but `--sysroot`
has no influence over this. Yet, we check for the presence of either
switch to determine whether we ought to warn about a missing SDK
*headers*.
- The presence of `-isysroot` is ignored when deciding whether to warn
about missing SDK *libraries*, depsite it being the only switch capable
of specifying a non-default SDK location.
- The `--sysroot`s passed to the PlayStation linkers by the driver are
unrelated to the SDK directory resolved in the PS4PS5Base constructor.
Following this change, we attempt to derive an SDK root from a platform-
specific environment variable. Failing that, we derive it from the location of
the driver. This then becomes the default root directory for both header and
library search. `--sysroot` overrides both search roots. `-isysroot` overrides
only the header search root. If both are specified, `--sysroot` specifies the
library search root and `-isysroot` specifies the header search root.
For each search root that was not overridden, a warning is emitted if expected
header/library search paths are missing inside that root.
The test updates to ps{4,5}-sdk-root.c were of the scale of a rewrite so
I also took the opportunity to clarify the purpose of each part,
eliminate some redundancy and add some missing coverage.
SIE tracker: TOOLCHAIN-16704
This patch will make LLVM emit a new section .llvm_jump_table_sizes
containing tuples of (jump table address, entry count) in object files.
This section is useful for tools that need to statically reconstruct the
control flow of executables.
At the moment this is only enabled by default for the PS5 target.
The PlayStation drivers emit warnings if it looks like SDK libraries are
missing. Until this point, the check was skipped when either `-nostdlib`
or `-nodefaultlibs` was supplied. I believe the idea is that if you
aren't linking default libraries, you won't be in need of the SDK.
However, in a situation where these switches are supplied, users may
still want to pass `-lSomeSDKLib` to the driver/linker with the
expectation that libSomeSDKLib.a will be sourced from the SDK. That is,
`-nodefaultlibs` and `-nostdlib` affect the libraries passed to the
linker, but not the library search paths.
So this change removes `-nostdlib`/`-nodefaultlibs` from consideration
when deciding whether or not to probe for the SDK's existence.
N.B. complete behaviour for `-nostdlib` and `-nodefaultlibs` is yet to
be added to the PlayStation compiler drivers. Coming soon.
SIE tracker: TOOLCHAIN-16704
The PS5 linker currently forces `-pie` for typical link jobs. Have the
driver pass `pie` under the same conditions. With this change we can
remove our private linker patch and also allow `-no-pie` to have an
effect.
SIE tracker: TOOLCHAIN-16704
On PlayStation, allow users to supply -static to the linker, via the
driver.
An initial step. Later changes will have the PS5 driver supply
additional options to the linker, if and when -static is passed.
SIE tracker: TOOLCHAIN-16704
The driver doesn't know if LTO will occur at link time. That's
determined by the presence or absence of LLVM bitcode objects among
those ingested by the linker.
For this reason, LTO options for codegen etc must be passed to the
linker unconditionally. If LTO does not occur, these options have no
effect.
Also simplify the way LTO options are supplied to the PS4 linker.
`-lto-debug-options` and `-lto-thin-debug-options` are combined and
routed to the same place. So, always use the former, regardless of
full/thin LTO mode.
SIE tracker: TOOLCHAIN-16575
Some of SIE's post-mortem analysis infrastructure currently makes use of
.debug_aranges, so we'd like to ensure the section's presence in
PlayStation binaries. The simplest way to do this is to force emission
when the debugger tuning is set to SCE (which is in turn typically
initialized from the target triple). This also simplifies the driver.
llvm/test/DebugInfo/debuglineinfo-path.ll has been marked as UNSUPPORTED
on PlayStation. When aranges are emitted, the DWARF in the test case is
such that relocations need to be applied to the aranges section in order
for symbolization to work. An alternative approach would be to implement
the application of relocations in DWARFDebugArangeSet. While experiments
show that this can be made to work with a modest patch, the test cases
would be rather contrived. Since I expect the only utility for such a
change would be to make this test case pass for PlayStation targets, and
few - if any - outside of PlayStation care about aranges, UNSUPPORTED
would seem to be a more practical option.
This was originally commited as 22eb290a96 (#99629) and later reverted
at 84658fb82b (#99711) due to test failures on SIE built bots. These
failures shouldn't recur due to 3b24e5d450 (#99897) and the
aforementioned change to debuglineinfo-path.ll.
SIE tracker: TOOLCHAIN-16951
Some of SIE's post-mortem analysis infrastructure currently makes use of
.debug_aranges, so we'd like to ensure the section's presence in
PlayStation binaries. The simplest way to do this is force emission when
the debugger tuning is set to SCE (which is in turn typically
initialized from the target triple). This also simplifies the driver.
SIE tracker: TOOLCHAIN-16951
It has long been the case on PlayStation that the linker itself has
taken on much of the responsibility that is traditionally the domain of
the C language driver elsewhere: which linker script to use, selection
of CRT objects, and so forth.
This is changing on PS5. The driver will assume responsibility for such
things. However, the situation on PS4 will remain as-is. To accommodate
this divergence, we must first separate how linker Jobs are created.
`clang/test/Driver/ps4-linker.c` has been similarly split for related
reasons.
In subsequent changes, PS5-specific linking behaviour can be moved from
SIE private patches in the PS5 linker to the (upstream) driver without
affecting the behaviour or implementation of PS4.
Adjust the PS5 driver defaults for the -fvisibility-from-dllstorageclass
sub-options so that only globals with dllimport/dllexport annotations
are adjusted. This allows globals without dllimport/export to retain
the visibility and pre-emptability assigned during IR-Gen. Set
-fvisibility=hidden on PS5 by default to compensate for no longer
overriding the visibility of definitions without dllexport. Note there
is no behavior change for PS4 (the behavior of overriding the
visibility for all globals is retained on PS4).
[Sema] Add `-fvisibility-global-new-delete=` option (#75364)
By default the implicitly declared replaceable global new and delete
operators are given a default visibility attribute. Previous work, see:
https://reviews.llvm.org/D53787, added
`-fvisibility-global-new-delete-hidden` to change this to a hidden
visibility attribute.
This change adds `-fvisibility-global-new-delete=` which controls
whether (or not) to add an implicit visibility attribute to the implicit
declarations for these functions, and what visibility that attribute
will specify. The option takes 4 values: `force-hidden`,
`force-protected`, `force-default` and `source`. Option values
`force-hidden`, `force-protected` and `force-default` assign hidden,
protected, and default visibilities respectively; the use of the term
force in the value names is designed to imply to a user that the semantics
of this option differ significantly from `-fvisibility=`. An option
value of `source` implies that no implicit attribute is added; without
the attribute the replaceable global new and delete operators behave
normally (like other functions) with respect to visibility attributes,
pragmas and options.
The motivation for the `source` value is to facilitate users who intend
to replace these functions either for a single linkage unit or a limited
set of linkage units. `-fvisibility-global-new-delete=source` can be
applied globally to the compilations in a build where the existing
`-fvisibility-global-new-delete-hidden` cannot, as it conflicts with a
common pattern where these functions are dynamically imported.
The existing `-fvisibility-global-new-delete-hidden` is now a deprecated
spelling of `-fvisibility-global-new-delete=force-hidden`
A release note has been added for these changes.
`-fvisibility-global-new-delete=source` will be set by default for PS5.
PS5 users that want the normal toolchain behaviour will be able to
supply `-fvisibility-global-new-delete=force-default`.
Instead of warning possibly up to 3 times about the same problem,
warn only about the actual missing directories.
This reverts commit 9b3323d39f635db870de958f067c672f54d7b192.
The warning will stay DefaultIgnore upstream, because a variety of
tests aren't expecting it and updating the tests isn't worth the
effort.
The unified LTO pipeline creates a single LTO bitcode structure that can
be used by Thin or Full LTO. This means that the LTO mode can be chosen
at link time and that all LTO bitcode produced by the pipeline is
compatible, from an optimization perspective. This makes the behavior of
LTO a bit more predictable by normalizing the set of LTO features
supported by each LTO bitcode file.
Example usage:
# Compile and link. Select regular LTO at link time.
clang -flto -funified-lto -fuse-ld=lld foo.c
# Compile and link. Select ThinLTO at link time.
clang -flto=thin -funified-lto -fuse-ld=lld foo.c
# Link separately, using ThinLTO.
clang -c -flto -funified-lto foo.c # -flto={full,thin} are identical in
terms of compilation actions
clang -flto=thin -fuse-ld=lld foo.o # pass --lto=thin to ld.lld
# Link separately, using regular LTO.
clang -c -flto -funified-lto foo.c
clang -flto -fuse-ld=lld foo.o # pass --lto=full to ld.lld
The RFC discussing the details and rational for this change is here:
https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774
-e has the LinkerInput flag (commit fcf8ada18f9cfb1261262e4b0399ae9ab40451f8)
and is rendered by AddLinkerInputs. We should remove duplicate rendering (e.g.,
`Args.AddAllArgs(CmdArgs, options::OPT_e)`).
Currently, we pass multiple LTO debug options to orbis-ld like this:
orbis-ld --lto=thin --lto-thin-debug-options=<arg1> --lto-thin-debug-options=<arg2> ...
When it should be like this:
orbis-ld --lto=thin "--lto-thin-debug-options= <arg1> <arg2>" ...
Differential Revision: https://reviews.llvm.org/D147546
This follows how OpenBSD, FreeBSD, and NetBSD now work. (See
D138183 and D140817 for those cases.)
It also tidies up some code duplication that wasn't exactly right.
This flag enables the .debug_aranges section by passing a flag to LLD
and our internal linker. This also adds a new routine that will generate
the correct flag for our internal linker or set of flags for LLD when
given a list of LLVM options. That ensures multiple LLVM codegen options
can be passed to either linker consistently.
Differential Revision: https://reviews.llvm.org/D134296
This adds a PS5-specific ToolChain subclass, which defines some basic
PS5 driver behavior. Future patches will add more target-specific
driver behavior.
The driver uses class SanitizerArgs to store parsed sanitizer arguments. It keeps a cached
SanitizerArgs object in ToolChain and uses it for different jobs. This does not work if
the sanitizer options are different for different jobs, which could happen when an
offloading toolchain translates the options for different jobs.
To fix this, SanitizerArgs should be created by using the actual arguments passed
to jobs instead of the original arguments passed to the driver, since the toolchain
may change the original arguments. And the sanitizer arguments should be diagnose
once.
This patch also fixes HIP toolchain for handling -fgpu-sanitize: a warning is emitted
for GPU's not supporting sanitizer and skipped. This is for backward compatibility
with existing -fsanitize options. -fgpu-sanitize is also turned on by default.
Reviewed by: Artem Belevich, Evgenii Stepanov
Differential Revision: https://reviews.llvm.org/D111443
415f7ee883 had LIT test failures on any build where the clang executable
was not called "clang". I have adjusted the LIT CHECKs to remove the
binary name to fix this.
Original commit message:
For PlayStation we offer source code compatibility with
Microsoft's dllimport/export annotations; however, our file
format is based on ELF.
To support this we translate from DLL storage class to ELF
visibility at the end of codegen in Clang.
Other toolchains have used similar strategies (e.g. see the
documentation for this ARM toolchain:
https://developer.arm.com/documentation/dui0530/i/migrating-from-rvct-v3-1-to-rvct-v4-0/changes-to-symbol-visibility-between-rvct-v3-1-and-rvct-v4-0)
This patch adds the ability to perform this translation. Options
are provided to support customizing the mapping behaviour.
Differential Revision: https://reviews.llvm.org/D89970
