From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1706 invoked by alias); 13 Dec 2014 18:56:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 1695 invoked by uid 89); 13 Dec 2014 18:56:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 13 Dec 2014 18:56:56 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBDIupMF028250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 13 Dec 2014 13:56:51 -0500 Received: from host2.jankratochvil.net (ovpn-116-142.ams2.redhat.com [10.36.116.142]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBDIum0u023915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 13 Dec 2014 13:56:50 -0500 Date: Sat, 13 Dec 2014 18:56:00 -0000 From: Jan Kratochvil To: Doug Evans , Eli Zaretskii Cc: gdb-patches Subject: Re: path to find libcc1.so? Message-ID: <20141213185647.GA14208@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83mw6sq941.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00330.txt.bz2 On Sat, 13 Dec 2014 01:22:38 +0100, Doug Evans wrote: > I was reading the new "compile" code and a question occurred to me. > Do we want to give the user a parameter to specify the path of libcc1.so? > (say if it's in a non-standard location) > Or is the plan to tell users to use existing mechanisms > (LD_LIBRARY_PATH, et.al.)? It is assumed + I use $LD_LIBRARY_PATH. I find the GDB compile project is at much too early stage than to care about this. It needs some additional features (such as to use it by default for the "print" command etc. etc.) to make it really practically useful, additionally it will be useful IMO only since the C++ support which is a new project ahead. But if we should care about it: I think libcc1.so can be arbitrary one, it only provides RPC interface to the target compiler which it fork()s+exec()utes. Target compiler is already being search to match the inferior arch (see GDB gdbarch's gnu_triplet_regexp). There is gdb<->libcc1 version check (GCC_FE_VERSION_0) and libcc1<->gcc version check (GCC_C_FE_VERSION_0) but so far there exists only one protocol version so I also find a bit premature to deal with searching for matching libcc1 when currently any one has to match. I wanted to try to check how does it search+work with s390x cross target but I failed to build gcc-5.0 for s390x, filed: s390x, ICE, unable to generate reloads, in curr_insn_transform, at lra-constraints.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300 On Sat, 13 Dec 2014 08:53:02 +0100, Eli Zaretskii wrote: > > Date: Fri, 12 Dec 2014 16:22:38 -0800 > > From: Doug Evans > > Cc: gdb-patches > > > > I was reading the new "compile" code and a question occurred to me. > > Do we want to give the user a parameter to specify the path of libcc1.so? > > Shouldn't "gcc -print-file-name" know how to find it? While 'gcc -print-file-name=libcc1.so' really works for me it brings a chicken-and-egg problem. Currently the search for a matching compiler (like x86_64-redhat-linux-gcc vs. s390x-linux-gnu-gcc) is being done by libcc1.so which ... is backwards. Jan