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
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.
