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 95AC93858CDA for ; Tue, 30 Jan 2024 19:51:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 95AC93858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 95AC93858CDA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706644272; cv=none; b=KEBsYABDwtCB8rCH3bE8ycPmPzUNH1kV8OLI+zo2TkifyBBk/SBxYy5zcjAR27V1MIwVBiEbKAROIgRXb50XzegbT5tIHC6eFCpQVBNIl1rFSFRYQf5mxkkKH9nFH44zotQ3Zv37RAhoHxmw3A0rL3XPL+sE4Jr4N5UxkNo0m2M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706644272; c=relaxed/simple; bh=Jk4x0JDU1B1f7b83kRdLSnqw7bLEY62HcuIwur4l3ao=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=X35akyGiJtguc2UxBg9epPJ0hjq4nzTorPHso+TfHYy5KCLRPWiqqNQHktO3hBccMqFd822LEO/4Qm/BUctcxRIQZCK89iXXjKGMHPym+r2oY8Tih9P7effz9tpR0gOmIv/9sxXk75Hp9xq6zfNDITJBGFGxgtTEt9OTGZwS1O4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1706644269; bh=Jk4x0JDU1B1f7b83kRdLSnqw7bLEY62HcuIwur4l3ao=; h=Date:Subject:To:References:From:In-Reply-To:From; b=vPCNMu/OWhqm0btoe2zNcJOmAmGwzS71Y1g20BZjWzh2qq8BMKw0DDYvRicMgz3Ns UFgWWFtH4/SFEi7ZqZfB1My/oKPKtfBsyqVwP+YkMtPmnbyaIUaXbAF97WM9FyAxM2 wo1iduh3J1Y1C82pS4Y4gAPDVdwbYXd2SnSuqMpQ= Received: from [10.0.0.170] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id DDA741E092; Tue, 30 Jan 2024 14:51:09 -0500 (EST) Message-ID: <46ff7883-17b2-490c-83aa-2c8e0bb1e95f@simark.ca> Date: Tue, 30 Jan 2024 14:51:09 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/testsuite: make gdb.base/list-nodebug.exp pass without libc symbols Content-Language: fr To: Guinevere Larsen , gdb-patches@sourceware.org References: <20240130093029.170544-2-blarsen@redhat.com> <08392c1c-41e4-4011-aa68-a8d6c6321556@redhat.com> From: Simon Marchi In-Reply-To: <08392c1c-41e4-4011-aa68-a8d6c6321556@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 1/30/24 11:48, Guinevere Larsen wrote: > On 30/01/2024 17:34, Simon Marchi wrote: >> On 1/30/24 04:30, Guinevere Larsen wrote: >>> Simon noticed that the test gdb.base/list-nodebug.exp would fail if >>> the system doesn't have debug symbols for the standard library, and >>> filed it as PR gdb/31290. The issue is that, if GDB finds no symbols >>> at all for, it takes a different exit than if it finds some symbols, >>> but nothing for the current location. >>> >>> This patch changes the test to accept any message, since the >>> important thing we're testing at this point is if GDB would crash, >>> not what the message is. --- Email only: >>> >>> I tried to condense the errors instead of changing the testcase, but >>> I couldn't find a good way to check if there were no symbols. My >>> best idea was to check if the symtab that was found has a linetable, >>> and exit error out if no linetable is present. However, I worry that >>> a user may want, for example, to list a specific function and I >>> couldn't convince myself that the linetable was required for that, >>> so I decided to go this safe route instead. >>> >>> If the linetable is required, or it is at least reasonable ot >>> require it for listing a file, I can send the other patch instead. >> I guess what you are referring to here is what I complained about on >> IRC, which is that without debug info for libc, we get: >> >> Breakpoint 1, 0x000055555555511d in main () (gdb) list . No >> symbol table is loaded. Use the "file" command. >> >> and with debug info for libc, we get: >> >> Breakpoint 1, 0x000055555555511d in main () (gdb) list . No >> debug information available to print source lines. >> >> Note that in both cases, we don't have debug info for the objfile >> where "main" is. In the first case, we have zero debug info for the >> inferior, and in the second case, we have some debug info for the >> inferior (for libc), just not for the objfile containing "main". >> >> My complaint is that the difference between these two cases isn't >> relevant to the user, so I think the message printed should be the >> same in both cases. With "list .", the user asks to print the source >> lines matching the current PC. Having or not having debug info for >> libc doesn't matter here. The different messages are just the result >> of some implementation details inside GDB. > > Yes that's exactly what I was referring to. It was bothering me for > longer than that, though. > > My analysis of the problem is that list_command uses > get_current_source_symtab_and_line, which will always return _some_ > symtab if there are any to be found, and will error out otherwise. > When it errors out (no libc debuginfo), we get the "No symbol table is > loaded" message. When it doesn't (with libc debuginfo) it will return > the symtab for libc, list_command will continue going and find the > current symtab and line through find_pc_line, and if there is no > symtab for the current we get the new error. > > Catching the error from get_current_source_symtab_and_line doesn't > sound too difficult, but I also wanted to avoid a situation where you > try "list" in that situation and GDB attempts to print libc lines > instead of main. I accidentally forgot that this wasn't part of what > we talked about on IRC, oops. The difficulty comes from figuring out > how we should figure out if the symtab that > get_current_source_symtab_and_line returns the correct symtab, and one > with debuginfo. My guess for checking if a symtab has debuginfo was to > see if it has a linetable, but I wasn't sure if that was a correct > assumption, and we still have the issue of a wrong symtab to deal > with, which wasn't trivial. What I was wondering when looking at it the other day is: why do we need to call get_current_source_symtab_and_line at all in a case where we don't care about the "current" location? Early in the function, we have: symtab_and_line cursal = get_current_source_symtab_and_line (); But in the `else if (arg[0] == '.')` portion of the function, it looks like we override `cursal` with something else. So, it is possible to call get_current_source_symtab_and_line only in the scopes that actually require it? Simon