From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 916B9385BF83 for ; Mon, 6 Apr 2020 18:03:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 916B9385BF83 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-190-G0rQtkycP8qK9jfzGcHf1g-1; Mon, 06 Apr 2020 14:03:39 -0400 X-MC-Unique: G0rQtkycP8qK9jfzGcHf1g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7F96E800D4E; Mon, 6 Apr 2020 18:03:38 +0000 (UTC) Received: from ovpn-114-204.phx2.redhat.com (ovpn-114-204.phx2.redhat.com [10.3.114.204]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2887CB19C8; Mon, 6 Apr 2020 18:03:38 +0000 (UTC) Message-ID: <7829390a7b7c0ce40a75f195189ea62a43252b45.camel@redhat.com> Subject: Re: [PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET From: Jeff Law Reply-To: law@redhat.com To: "Maciej W. Rozycki" , libffi-discuss@sourceware.org Cc: gcc-patches@gcc.gnu.org Date: Mon, 06 Apr 2020 12:03:37 -0600 In-Reply-To: References: Organization: Red Hat User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-15.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_2, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 18:03:42 -0000 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 >