public inbox for libffi-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@wdc.com>
To: libffi-discuss@sourceware.org
Cc: Anthony Green <green@moxielogic.com>,
	Mike Stump <mikestump@comcast.net>,
	 gcc-patches@gcc.gnu.org
Subject: [PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET
Date: Fri, 3 Apr 2020 23:56:16 +0100 (BST)	[thread overview]
Message-ID: <alpine.LFD.2.21.2004031400230.461@redsun52.ssa.fujisawa.hgst.com> (raw)
In-Reply-To: <alpine.LFD.2.21.2004012222200.461@redsun52.ssa.fujisawa.hgst.com>

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(-)

Index: libffi/testsuite/lib/libffi.exp
===================================================================
--- libffi.orig/testsuite/lib/libffi.exp
+++ libffi/testsuite/lib/libffi.exp
@@ -272,7 +272,7 @@ proc libffi-init { args } {
     global srcdir
     global blddirffi
     global objdir
-    global TOOL_OPTIONS
+    global CC_FOR_TARGET
     global tool
     global libffi_include
     global libffi_link_flags
@@ -287,29 +287,63 @@ proc libffi-init { args } {
     verbose "libffi $blddirffi"
 
     if { [string match $compiler_vendor "gnu"] } {
-        set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
-        if {$gccdir != ""} {
-	    set gccdir [file dirname $gccdir]
-        }
+	if [info exists CC_FOR_TARGET] then {
+	    set compiler "$CC_FOR_TARGET"
+	    set libgcc_a_x [remote_exec host "$compiler" \
+			    "-print-file-name=libgcc.a"]
+	    if { [lindex $libgcc_a_x 0] == 0 } {
+		set gccdir [file dirname [lindex $libgcc_a_x 1]]
+	    } else {
+		set gccdir ""
+	    }
+	} else {
+	    set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
+	    if {$gccdir != ""} {
+		set gccdir [file dirname $gccdir]
+	    }
+	    set compiler "${gccdir}/xgcc"
+	}
         verbose "gccdir $gccdir"
 
+	set shlib_ext [get_shlib_extension]
+	set libgcc_s_x [remote_exec host "$compiler" \
+			"-print-file-name=libgcc_s.${shlib_ext}"]
+	if { [lindex $libgcc_s_x 0] == 0 } {
+	    set libgcc_dir [file dirname [lindex $libgcc_s_x 1]]
+	} else {
+	    set libgcc_dir $gccdir
+	}
+	verbose "libgcc_dir $libgcc_dir"
+
         set ld_library_path "."
         append ld_library_path ":${gccdir}"
 
-        set compiler "${gccdir}/xgcc"
-        if { [is_remote host] == 0 && [which $compiler] != 0 } {
-	    foreach i "[exec $compiler --print-multi-lib]" {
-	        set mldir ""
-	        regexp -- "\[a-z0-9=_/\.-\]*;" $i mldir
-	        set mldir [string trimright $mldir "\;@"]
-	        if { "$mldir" == "." } {
+	set multi_dir_x [remote_exec host "$compiler" "-print-multi-directory"]
+	set multi_lib_x [remote_exec host "$compiler" "-print-multi-lib"]
+	if { [lindex $multi_dir_x 0] == 0 && [lindex $multi_lib_x 0] == 0 } {
+	    set multi_dir [string trim [lindex $multi_dir_x 1]]
+	    set multi_lib [string trim [lindex $multi_lib_x 1]]
+	    if { "$multi_dir" == "." } {
+		set multi_root "$libgcc_dir"
+	    } else {
+		set multi_match [string last "/$multi_dir" "$libgcc_dir"]
+		if { "$multi_match" >= 0 } {
+		    set multi_root [string range "$libgcc_dir" \
+				    0 [expr $multi_match - 1]]
+		} else {
+		    set multi_lib ""
+		}
+	    }
+	    foreach i "$multi_lib" {
+		set mldir ""
+		regexp -- "\[a-z0-9=_/\.-\]*;" $i mldir
+		set mldir [string trimright $mldir "\;@"]
+		if { "$mldir" == "$multi_dir" } {
 		    continue
-	        }
-	        if { [llength [glob -nocomplain ${gccdir}/${mldir}/libgcc_s*.so.*]] >= 1 } {
-		    append ld_library_path ":${gccdir}/${mldir}"
-	        }
+		}
+		append ld_library_path ":${multi_root}/${mldir}"
 	    }
-        }
+	}
     }
 
     # add the library path for libffi.

  parent reply	other threads:[~2020-04-03 22:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-03 22:55 [PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite Maciej W. Rozycki
2020-04-03 22:55 ` [PATCH libffi 1/4] Use a template to pass $CC and $CXX to DejaGNU Maciej W. Rozycki
2020-04-06 17:58   ` Jeff Law
2020-04-03 22:55 ` [PATCH libffi 2/4] Use a documented way to pass $compiler_vendor " Maciej W. Rozycki
2020-04-06 18:00   ` Jeff Law
2020-04-03 22:56 ` Maciej W. Rozycki [this message]
2020-04-06 18:03   ` [PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET Jeff Law
2020-04-03 22:56 ` [PATCH libffi 4/4] Correct indentation throughout `libffi-init' Maciej W. Rozycki
2020-04-06 18:01   ` Jeff Law
2020-04-14 13:59 ` [PING][PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite Maciej W. Rozycki
2020-04-20 12:50 ` [PING^2][PATCH " Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.21.2004031400230.461@redsun52.ssa.fujisawa.hgst.com \
    --to=macro@wdc.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=green@moxielogic.com \
    --cc=libffi-discuss@sourceware.org \
    --cc=mikestump@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).