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.133.124]) by sourceware.org (Postfix) with ESMTPS id 66CC938582A8 for ; Wed, 31 Jan 2024 14:49:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 66CC938582A8 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 66CC938582A8 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706712590; cv=none; b=W14vnb4vMXkH7UlsnuJbImsbF1v/0I5UbAQsrrc5qGj7f0sq0dj98i2wQ8yCanJFt7uR1kjSNdeFKQlI/+H+8a9LtN4XLQkwp9Z7JLh1xk8pdpdT68mDIIBK6u6ke/PWmBn4EtXMwYECMf7MiqCJpeKYUVCbOvTGQlVR6eNGUHs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706712590; c=relaxed/simple; bh=/Apv37akedyDAZYvMaH5bQeSuQPKME0GxdMWmREDdug=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=nltLrphciOXeAXipoxlt/tjKXu/5JFSwfjUoQBRv3aDWs77PMXY/rnu/x4GjoYyhs6Ha036we/FSvTnGvqHGaBho4iDQ2fMVV0bms6udnhi5L8PNbEQRM9Va9rebtd7vctXlUoNLHUFLl3CwAdU56TYZO/U4gnrsu2/RtBNuYNQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1706712588; 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=5l7lBrJXeW5ED68UnKhl96eHkQ1FOcj1+qHzQrW7Jos=; b=XORwMqSLIh33WFYan+wAuKQkQGHpxIlaA3JH33NXMquDzTsFDVZlLpCtXIaYy6t/1Z+8P8 otOBQeC2iE6SsJKow5h/qUx3zmdgMZnhIONQFkm6uCmEd6gEoPiJccANqCrYpJUbh720ZV C33eMcqG31WpX+j17IXUsz7xzkWqIXM= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-330-pz9BjrzPNBCv2_Yjtsztqg-1; Wed, 31 Jan 2024 09:49:44 -0500 X-MC-Unique: pz9BjrzPNBCv2_Yjtsztqg-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-40fb74433ebso583255e9.3 for ; Wed, 31 Jan 2024 06:49:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706712583; x=1707317383; h=content-transfer-encoding:in-reply-to:from:content-language :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=5l7lBrJXeW5ED68UnKhl96eHkQ1FOcj1+qHzQrW7Jos=; b=lKtMABqZHDWey6903eV3NGYNNvpnp108rHCUXd4286HEHLBtnU+4Z1KN0oEHQ0APq6 IpvYN/9YYI84Wv/WCkbroyPZMRlCX7HS3pbtDTgD9UZYDeV++UHDJUMSSZbbSKvj0/Zz cN7fEARxCmSuzGx2088kfjRh2fMj9RRim4lMIaJUAL8XocXe7ZQBaegPI4OF+hq/6EQH fReUP5BjI3wmT8LeNIO2DYRTQ3o+FDv1jfi3MasDJkxUpCKNmRwEuoihkf4tLdm3aFmC Kj74HUeLDVaAj+4epLj+/vBcT2lPsTUc6EU5mbZNRD0x3kOH0pqBZtY8WMOTRz7VY7MJ JPuw== X-Gm-Message-State: AOJu0YxhDErF75mtyTXYYxQ23D5G1WhQAVJlvLyFtBpNtKgiG0IirWl8 iO73YVfSOt7kM1MkCCKBP5GeW2Vbk+il/sPvBg86zBX0aPPanExqCcoA5DZ44wNPeeCNTSV2vUx RO+uoFh/I9DG48aYwHeqE50MM9LXhuFg0JNdv+4ZJbpG8Ya6pOK+KC79nbZ5o+L/5zIc= X-Received: by 2002:a05:600c:4fc5:b0:40e:55ca:5a48 with SMTP id o5-20020a05600c4fc500b0040e55ca5a48mr1757506wmq.16.1706712583644; Wed, 31 Jan 2024 06:49:43 -0800 (PST) X-Google-Smtp-Source: AGHT+IFY8ZnGA9/3SM/aSanCMbzNaq0eeSAioQojyX3pBz7jZBazb58dh8L/2dZWnUMiSqkWS4FCZw== X-Received: by 2002:a05:600c:4fc5:b0:40e:55ca:5a48 with SMTP id o5-20020a05600c4fc500b0040e55ca5a48mr1757493wmq.16.1706712583267; Wed, 31 Jan 2024 06:49:43 -0800 (PST) Received: from [192.168.0.129] (ip-94-112-227-180.bb.vodafone.cz. [94.112.227.180]) by smtp.gmail.com with ESMTPSA id v8-20020a05600c444800b0040e54f15d3dsm1822916wmn.31.2024.01.31.06.49.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Jan 2024 06:49:42 -0800 (PST) Message-ID: <815736c9-66fa-4181-8847-4c94c455a905@redhat.com> Date: Wed, 31 Jan 2024 15:49:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb/testsuite: make gdb.base/list-nodebug.exp pass without libc symbols To: Simon Marchi , gdb-patches@sourceware.org References: <20240130093029.170544-2-blarsen@redhat.com> <08392c1c-41e4-4011-aa68-a8d6c6321556@redhat.com> <46ff7883-17b2-490c-83aa-2c8e0bb1e95f@simark.ca> From: Guinevere Larsen In-Reply-To: <46ff7883-17b2-490c-83aa-2c8e0bb1e95f@simark.ca> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no 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 30/01/2024 20:51, Simon Marchi wrote: > 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? "current" is a poorly defined term in this context. what the `.` argument means with "current" is point of execution of the inferior, what get_current_source_symtab_and_line means by "current" is the location that is being printed. I say this based on the fact that list with no arguments or with '+' use this "current" sal to continue printing the file. > > 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? As I mentioned, this gets used by no arg and '+', but I'm not sure if it is necessary. We can define cursal only when first printing and for '.', using get_last_line_printed for the rest. That's besides the point, the important part is that this is the only location (other than '.' recently added) that is able to tell if the inferior has debuginfo, so we have to handle its error somewhere if we want to have a single message for all list errors. > Simon > -- Cheers, Guinevere Larsen She/Her/Hers