Re: [PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET

[Jeff Law <law@redhat.com>]

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
>