From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by sourceware.org (Postfix) with ESMTPS id 949DD3857C5F for ; Wed, 24 Mar 2021 16:55:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 949DD3857C5F Received: by mail-qt1-x836.google.com with SMTP id l13so18036277qtu.9 for ; Wed, 24 Mar 2021 09:55:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=nGP2NibCB0oF/NVBmxydkFbE7nSldpfkx9DkklBbXJA=; b=JJ0ywTHnjZxXb+R8lHyFU/R9T8SqoNrGJ9bd7rUOqR10YLmqZvbmo6oBBDDldvvPtM N4vMRvMklbIvCaBU0GNgoZ1nH1gBowkyYrYY/Mk1FWYp+bJAz+MEdrB3+/sFiJNW7qGE Nf3Ifwq2yFN2rJFZNGZu5uf27iTuMz4Day04uD6MftlUYzSazYKHajbXX+vYo7cpWwKV ehnsPqN48AKTaAqqovn6FnE2XVCX7fik49IRQBhVKwtnA4JImuKIt228EQdO0CZr+RD9 07Yuan3hL/UFLQQaecShZ0Ke9hX9SiQWSErVkWw+BGQ2+W8DznDzTnQ8NlMos2rpChVL u6NQ== X-Gm-Message-State: AOAM532jh6kAh6j2z+AjRgsmxwyQLrvYpY5HaJdrkEd4X0EZVousaX9e FOXxrAxh9nrWUB5lJR7XIQZiBw== X-Google-Smtp-Source: ABdhPJy6ZoMtdrF41bH8YBJY7Bly3P2nUF+5dedERW+9XttU4ODj3zh/Hbqz9GPfaECwvOoS4zvJMg== X-Received: by 2002:ac8:4a18:: with SMTP id x24mr3833518qtq.33.1616604950114; Wed, 24 Mar 2021 09:55:50 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:2841:ad61:3bf4:83da:f1f1? ([2804:7f0:4841:2841:ad61:3bf4:83da:f1f1]) by smtp.gmail.com with ESMTPSA id l17sm1714218qtk.60.2021.03.24.09.55.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Mar 2021 09:55:49 -0700 (PDT) Subject: Re: Broken libcc1 lookup in GDB/Ubuntu To: Ruslan Kabatsayev Cc: "gdb@sourceware.org" , jan.kratochvil@redhat.com, Jeff Law References: <51acf4b8-5c69-d9e4-c155-e7af083a3c33@linaro.org> From: Luis Machado Message-ID: <6a506f33-c4c3-e893-e372-0e747a03f474@linaro.org> Date: Wed, 24 Mar 2021 13:55:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, 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: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 16:55:53 -0000 On 3/24/21 1:45 PM, Ruslan Kabatsayev wrote: > Hi, > > On Wed, 24 Mar 2021 at 18:15, Luis Machado via Gdb wrote: >> >> Hi, >> >> While looking at enabling the compile tests in GDB's testsuite, I >> noticed GDB doesn't find the right shared library because it is looking >> for a different naming pattern. >> >> In the case of Ubuntu 18.04/20.04, the shared library is named like so: >> >> /usr/lib/aarch64-linux-gnu/libcc1.so.0.0.0 >> /usr/lib/aarch64-linux-gnu/libcc1.so.0 -> libcc1.so.0.0.0 > > "apt-file search libcc1.so" shows me that e.g. gcc-9 package (and > other versions of gcc) provides the suffixless version. It's installed > as a symlink into /usr/lib/gcc/aarch64-linux-gnu/9/libcc1.so . Can it > not be found? > Those do exist, but GDB seems to want to load that library from /usr/lib/aarch64-linux-gnu, and not from, say, /usr/lib/aarch64-linux-gnu/9/libcc1.so. There is no symlink from /usr/lib/aarch64-linux-gnu/libcc1.so.0 pointing at the version-specific file. >> >> But GDB is looking for libcc1.so in the following ways: >> >> #define GCC_C_FE_LIBCC libcc1.so >> #define GCC_CP_FE_LIBCC libcc1.so >> >> So, basically, the gdb.compile tests will never be exercised >> out-of-the-box, even if you install the libcc1 package. I had to add a >> symlink named "libcc1.so" to make GDB happy. >> >> Now, I noticed there was a proposed fix for this many years ago, in the >> following series: >> >> https://gcc.gnu.org/legacy-ml/gcc-patches/2015-04/msg01241.html >> https://gcc.gnu.org/legacy-ml/gcc-patches/2015-04/msg01242.html >> https://gcc.gnu.org/legacy-ml/gcc-patches/2015-04/msg01243.html >> https://gcc.gnu.org/legacy-ml/gcc-patches/2015-04/msg01244.html >> https://gcc.gnu.org/legacy-ml/gcc-patches/2015-04/msg01245.html >> >> Was this dropped for some reason? Or is this still valid and should be >> pursued upstream? >> >> >> Thanks, >> Luis > > Regards, > Ruslan >