[PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET
Jeff Law
law@redhat.com
Mon Apr 6 18:03:37 GMT 2020
On Fri, 2020-04-03 at 23:56 +0100, Maciej W. Rozycki via Gcc-patches wrote:
> Update code in `libffi-init' to use $CC_FOR_TARGET in determining the
> value of $ld_library_path, as using a different compiler location from
> one actually used in testing may have odd consequences.
>
> As this obviously loses the setting of $gccdir provide a replacement way
> to determine the directory if feasible, however prefer the location of
> shared libgcc over static libgcc. This helps in configurations where
> shared libgcc is, unlike libgcc, a location that is not specific to the
> compiler version, a common scenario. It does not address the scenario
> however where there is a shared libgcc symlink installed pointing to the
> actual run-time library installed elsewhere; this would have to be dealt
> with in a board description file specific to the installation.
>
> Use `remote_exec host' rather than `exec' to invoke the compiler so as
> to support remote configurations and also avoid the latter procedure's
> path length limitation that prevents execution in some actual scenarios.
>
> As using `remote_exec host' precludes the use of our existing file name
> globbing to examine directory contents, reuse, with minor modifications
> needed to adjust to our structure, the piece I previously contributed to
> GCC with commit d42b84f427e4 ("testsuite: Fix run-time tracking down
> of `libgcc_s'").
> ---
> Hi,
>
> This has its limitation in that it still doesn't default to the same
> compiler as `target_compile' (`default_target_compile') from target.exp in
> DejaGNU does, but I believe it is a step in the right direction. That
> will only affect standalone (e.g. installed) testing iff $CC_FOR_TARGET
> hasn't been set.
>
> Also for C++ compilation our carefully crafted $ld_library_path is
> unfortunately overridden by `g++_link_flags' from libgloss.exp in DejaGNU
> called in `default_target_compile'. This actually does cause test
> failures in my `riscv64-linux-gnu' cross-compilation setup:
>
> FAIL: libffi.closures/unwindtest.cc -W -Wall -Wno-psabi -O0 execution test
> FAIL: libffi.closures/unwindtest.cc -W -Wall -Wno-psabi -O2 execution test
> FAIL: libffi.closures/unwindtest_ffi_call.cc -W -Wall -Wno-psabi -O0 execution
> test
> FAIL: libffi.closures/unwindtest_ffi_call.cc -W -Wall -Wno-psabi -O2 execution
> test
>
> and I am currently not sure how to best address it, i.e. whether to change
> DejaGNU's `g++_link_flags' or to take advantage of a TCL's feature and
> provide our own copy of the procedure. Something to consider sometime.
>
> NB I chose not to correct obvious indentation issues with lines not
> touched by this change so as not to obfuscate the patch unnecessarily. A
> complementing formatting change follows.
>
> Maciej
> ---
> testsuite/lib/libffi.exp | 68 +++++++++++++++++++++++++++++++++++-----------
> -
> 1 file changed, 51 insertions(+), 17 deletions(-)
OK. Note that all 4 patches in the series need ChangeLog entries.
jeff
>
More information about the Libffi-discuss
mailing list