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 DECA738937E0 for ; Thu, 15 Dec 2022 16:35:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DECA738937E0 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 [172.16.0.64] (192-222-180-24.qc.cable.ebox.net [192.222.180.24]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8D0F21E0CD; Thu, 15 Dec 2022 11:35:48 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1671122148; bh=hDc3gBOVFbPnV5Fo2+gCJZzEDgwcK6qMs8gUDfAGbcM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=j7DeH/g9OugFhVjeoI1fRWQ77goQtEmNxyLjloIShZW9IZIapAjjU4/Y5nfBR3Cpv et1N1+dSH1QNPxEn+7U+yLB0TmSVwFY8PtC2ugyzIoRVF6LsjZ5kl0HSdU2n5cwLl+ oDRb+EHAWzs8aQ/FmgBVfrBTo/YUqh/KmuUTPH84= Message-ID: Date: Thu, 15 Dec 2022 11:35:48 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH] gdb: defer warnings when loading separate debug files Content-Language: fr To: =?UTF-8?Q?Alexandra_H=c3=a1jkov=c3=a1?= , gdb-patches@sourceware.org References: <20221212121535.4013497-1-ahajkova@redhat.com> From: Simon Marchi In-Reply-To: <20221212121535.4013497-1-ahajkova@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 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 12/12/22 07:15, AlexandraH á jkov á ahajkova--- via Gdb-patches wrote: > From: Alexandra Hájková > > Currently, when GDB loads debug information from a separate debug file, > there are a couple of warnings that could be produced if things go > wrong. > > In find_separate_debug_file_by_buildid (build-id.c) GDB can give a > warning if the separate debug file doesn't include any actual debug > information, and in separate_debug_file_exists (symfile.c) we can warn > if the CRC checksum in the separate debug file doesn't match the > checksum in the original executable. > > The problem here is that, when looking up debug information, GDB will > try several different approaches, lookup by build-id, lookup by > debug-link, and then a lookup from debuginfod. GDB can potentially give > a warning from an earlier attempt, and then succeed with a later > attempt. In the cases I have run into this is primarily a warning about > some out of date debug information on my machine, but then GDB finds the > correct information using debuginfod. This can be confusing to a user, > they will see warnings from GDB when really everything is working just > fine. > > For example: > warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" > does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). > > This diagnostic was printed on Fedora 33 even when the correct debuginfo > was downloaded. > > In this patch I propose that we defer any warnings related to looking up > debug information from a separate debug file. If any of the approaches > are successful then GDB will not print any of the warnings. As far as > the user is concerned, everything "just worked". Only if GDB completely > fails to find any suitable debug information will the warnings be > printed. I don't really like this behavior change. The situations you described: - a separate debug file without any actual debug information - CRC checksum that doesn't match ... are abnormal situations which still deserve being warned about, I think. If the files are there, it's because they are meant to be used, so if something prevents GDB from using them, I want to know. Silencing the warning just makes investigating "why doesn't GDB read my separate debug file" harder. I can understand why this can be a bit confusing to the user, but the warning is still factually correct. For instance, the one you quoted: warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). This doesn't say that GDB didn't end up finding *some* debug info for the shared object, just that this particular one is broken. Maybe it's an old one I installed by hand, that I should delete, maybe the package from the distro is broken. In any case it's good for the user to know so they can fix the situation. Simon