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 F415B3858D1E for ; Tue, 20 Dec 2022 02:29:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F415B3858D1E 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 E4E691E112; Mon, 19 Dec 2022 21:29:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1671503386; bh=cIfhp1pvcy5+yVwss8GO5Nnii4EjEaVtRRTLV4vBhFU=; h=Date:Subject:To:References:From:In-Reply-To:From; b=QlimV+iCeHBkU41xelrqR89DRq8rURHWKztS4uSONN9zrSsyI8uT7lTUrEhYZ7XBe mIy+oZJMJhql7vGumuWxRl0cDYGOi8iyXjvA+PkhFuq57XBoXWdYtCBfkvotuvQgOr jVa4KVLnu17OCKIsBxyebeyoML7oKbPDG4GT8N7Q= Message-ID: <737f6e56-efe3-1b5f-03cb-41a629692bf1@simark.ca> Date: Mon, 19 Dec 2022 21:29:45 -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: en-US To: Andrew Burgess , =?UTF-8?Q?Alexandra_H=c3=a1jkov=c3=a1?= , gdb-patches@sourceware.org References: <20221212121535.4013497-1-ahajkova@redhat.com> <87cz8fzc5u.fsf@redhat.com> From: Simon Marchi In-Reply-To: <87cz8fzc5u.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 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: > 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. Yeah that makes sense. But given that my view appears to be the exception, I'm fine with going with no message at all as well, if we think regular users don't care. I'm not a regular GDB user, that's probably why I want to be warned about everything that can possibly make GDB misbehave, so I can fix it. > 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. I personally would like to be warned, but you're probably right about the average user. > 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? Agreed, it's so difficult to figure out why GDB doesn't find separate debug info sometimes, we need good debug messages. Simon