From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6D5523858D1E for ; Mon, 19 Dec 2022 14:44:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D5523858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671461042; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dnLYrzraoJQhUfMhylwI45EsaLu9xpCR4ZuDpmFk7rY=; b=BK0ZqzAWGTfnVKzQvO9oSbUsLV/K+jtiaroUshV03YEsTPHjyBDRN7usioCAcVUSfJnbDc bx4aTzPGGg4ExCTnBOXmjKbFCGwdkC01BVl3tNtyT/mEjyyNLS9nNAqvEFwn5CwxQx4/gT GHUTBDLMTV1deZxJRCGjwkkrUYmksU4= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-623-HqjkiQ5TPX-jqevM4h20Zw-1; Mon, 19 Dec 2022 09:44:00 -0500 X-MC-Unique: HqjkiQ5TPX-jqevM4h20Zw-1 Received: by mail-wm1-f72.google.com with SMTP id b47-20020a05600c4aaf00b003d031aeb1b6so6675519wmp.9 for ; Mon, 19 Dec 2022 06:44:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:to:from:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=dnLYrzraoJQhUfMhylwI45EsaLu9xpCR4ZuDpmFk7rY=; b=rcIDgqucjCSRpm0prc3IHt+lfsu+nh4R0JwCE3W9ErK9wyArtw4YqJPBRn9pm5rx8Q McIQs9pCxTuBqxpEAZpTN2dwQXTjR8v4bz4dDaMR7vqffaK7ybsJ4AG2eG77yPBssD8I uqnySE8y5Fpdqf2exZD4sFStBKuqnOtfiAcASfFRzd9AEXdGJ+Bruu9OUBiB6VFb3J/5 xIBdRNWTtRA1NNMrowZ3OmYQ++zf0vuQHiuSRg+y4GYG0StiKx5ZgNBoRV+1OLACMFDm W1jm/6UPXwv9diZJ8wCBnSrkBU5Ds/6ny2asTzJswkXxfrsCKk6olQH4ACLsDYdenq0z G+mA== X-Gm-Message-State: ANoB5pkGXMG2x6qiAasi1NahRu7jWWR8Mps/E+CRkVCaKDB/yit2r742 eEElIvZYFjEz88RB+iKm4AoVNMqMTwe5Rbd8t3Sbe1a1sMJ2eRVjFJKf1I4e0tLA5qnRCsZEKbx cpikzsWaS6PxB92OGf8TpNA== X-Received: by 2002:a5d:4f92:0:b0:242:18c5:7899 with SMTP id d18-20020a5d4f92000000b0024218c57899mr29240344wru.61.1671461039308; Mon, 19 Dec 2022 06:43:59 -0800 (PST) X-Google-Smtp-Source: AA0mqf7EAfS4epZZe9rydnbb2kmbxCNdQZpZz1V15ncbXjXDPTS3kiWg3v6R8jUq47iNZx3Rp0Y2DA== X-Received: by 2002:a5d:4f92:0:b0:242:18c5:7899 with SMTP id d18-20020a5d4f92000000b0024218c57899mr29240335wru.61.1671461039050; Mon, 19 Dec 2022 06:43:59 -0800 (PST) Received: from localhost ([31.111.84.238]) by smtp.gmail.com with ESMTPSA id z7-20020a5d4407000000b0024245e543absm9898386wrq.88.2022.12.19.06.43.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Dec 2022 06:43:58 -0800 (PST) From: Andrew Burgess To: Simon Marchi , Alexandra =?utf-8?B?SMOhamtvdsOh?= , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: defer warnings when loading separate debug files In-Reply-To: References: <20221212121535.4013497-1-ahajkova@redhat.com> Date: Mon, 19 Dec 2022 14:43:57 +0000 Message-ID: <87cz8fzc5u.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: Simon Marchi via Gdb-patches writes: > On 12/12/22 07:15, AlexandraH =C3=A1 jkov =C3=A1 ahajkova--- via Gdb-patc= hes wrote: >> From: Alexandra H=C3=A1jkov=C3=A1 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> For example: >> warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.s= o.debug" >> does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch). >>=20 >> This diagnostic was printed on Fedora 33 even when the correct debuginfo >> was downloaded. >>=20 >> 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. In my experience, most users don't care where the debug info comes from, so long as GDB can find it somehow. > 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.3= 2.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. I think we should not underestimate the concern a warning can cause. Sure, it's not an error, but there are some users who, upon seeing a warning, will stop and seek help until they have resolved the issue for fear that it's important. Maybe if we extended the warning to say "... but don't worry I found some debug information elsewhere." then this would stop the worry? But, I would suggest that the above message could fall into a category below warning. In my mind the "levels" are: error - something went wrong and GDB can't continue, warning - something went wrong, GDB can continue, but your experience is not going to be what you expect in some way, info? (this doesn't exist right now) - just some useful information, but everything is just fine. The message Alexandra is changing could be an 'info' message when GDB is able to find debug elsewhere, but could be promoted to 'warning' when GDB is unable to find any alternative debug information. Right now, some 'info' messages are just printed to the console by GDB, e.g. when we print 'Reading symbols from /tmp/test...', but there are plenty of cases where GDB doesn't print out all the intermediate steps that it tries when looking for a result, e.g. if I do 'file ls' then GDB will find /usr/bin/ls, but GDB doesn't tell me where it looked and didn't find 'ls'. I know this isn't exactly the same, but, it isn't unrelated I think. > 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. In my experience, in most cases, the user doesn't care about fixing the problem, unless it is somehow stopping them debug their issue. If GDB can find what it needs, then I think most users don't care, things just work, and they're fine with that. And it's not like GDB is hiding what its doing, there are info messages printed that GDB is downloading a file, then that GDB is reading debug from the freshly downloaded file, so if the user does have some expectations about which debug file should be used, this should inform them that something isn't going quite right. Maybe one thing we could do, which might help in this area, would be, at the point where the (potential) warning is added to the warning list we could emit a debug print guarded by separate_debug_file_debug. That way, if a user asks the question, "why is GDB failing to find the expected debug file?", they can 'set debug separate-debug-file' and the answer would be there? Thanks, Andrew