From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 818AA3858D32 for ; Sun, 6 Nov 2022 00:57:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 818AA3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id A6B931E0D3; Sat, 5 Nov 2022 20:57:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1667696252; bh=cZYvsky/oAzEXNYAU/Tv0jHablw3di7ebGWP17E3wfs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=IWnbEV+MBb9W5rVwtIe13HMsO1iGMkZT2fTwbulupYCSiy6NN29o6A8dBjQQHSQtb G7WE7m7fNyKqphRJ33JECKiXRIl4lRRLi9puRYNCLn9c5oxzibW9QKr5z7jF7uAn4g 4S/xguKKuBSBKB1AwaBgg81RPEdtIHX1Zi+7SHvI= Message-ID: <0451acc2-1a75-bcc4-98f1-fd9782c5cd77@simark.ca> Date: Sat, 5 Nov 2022 20:57:31 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] gdb: link executables with libtool Content-Language: en-US To: "Jose E. Marchesi" Cc: Eli Zaretskii , indu.bhagat@oracle.com, gdb-patches@sourceware.org, elena.zannoni@oracle.com References: <20221105130827.1194771-1-jose.marchesi@oracle.com> <83v8nt3525.fsf@gnu.org> <871qqhiicr.fsf@oracle.com> <5a5ce25a-5baf-2bb1-d016-97ccf617ba25@simark.ca> <87eduhgtvr.fsf@oracle.com> From: Simon Marchi In-Reply-To: <87eduhgtvr.fsf@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 11/5/22 14:04, Jose E. Marchesi wrote: > >> On 11/5/22 10:30, Jose E. Marchesi via Gdb-patches wrote: >>> >>>>> Date: Sat, 5 Nov 2022 14:08:27 +0100 >>>>> From: "Jose E. Marchesi via Gdb-patches" >>>>> Cc: indu.bhagat@oracle.com, elena.zannoni@oracle.com >>>>> >>>>> This patch changes the GDB build system in order to use libtool to >>>>> link the several built executables. This makes it possible to refer >>>>> to libtool libraries (.la files) in CLIBS. >>>> >>>> If this is supposed to be installed before we start the release cycle >>>> of GDB 13, I question the wisdom of making such a significant change >>>> when we are so close to the next release. >>>> >>>> Does this solve some grave problems, or can we wait until after GDB >>>> 13? >>> >>> Basically it would unstuck us in getting the SFrame integration applied >>> in binutils. >>> >>> See >>> https://sourceware.org/pipermail/gdb-patches/2022-November/193381.html >>> >>> We could go with the simpler solution suggested in that email (already >>> used by libbacktrace and libctf) in GDB 13 and then we can apply the new >>> patch to switch to libtool for linking. >>> >>> I know Mike doesn't like the idea; but I hope we have proved we do our >>> homework? >> >> IIUC, it would not be useful to have the libtool changes without the >> SFrame changes. And given that the GDB 13 branch is supposed to be cut >> very shortly, do we expect to have the SFrame changes in GDB 13 (I have >> no idea what that consists of)? If not, then the libtool changes are >> not really needed in GDB 13. > > The SFrame support (it is a frame unwinding format) is purely in > binutils (assembler, and linker via BFD) and, per-se, it doesn't concern > GDB at all. > > The issue is that given the current way GDB links with BFD (directly > with the ../bfd/libbfd.a archive) it becomes necessary to also > explicitly list libbfd's dependencies in the GDB build system. In the > binutils SFrame patch we are introducing a libsframe in binutils, and > make libbfd link with it. Having to satify these kind of indirect > dependencies for in-tree libraries in the GDB build system is generally > not a good idea, and therefore Mike's suggestion on making GDB use > libtool for linking and the patch I sent. Thanks for the explanation. > The patch also eliminates GDB's reliance on libtool internal paths like > .libs/foo.so (alghough doing that it is something not unheard of ^^.) > > When is GDB 13 expected to be branched? I don't know, it's up to Joel. The latest update is: https://inbox.sourceware.org/gdb-patches/Y2K24aU9cNVXo0hC@adacore.com/T/#mfaac801866d08eedcd94b5ce85257389bdecfec6 Personally, I would not be too worried to see this change in GDB 13, but others (like Eli) may think differently. Simon