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 772E83858420 for ; Tue, 30 Jan 2024 16:48:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 772E83858420 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 772E83858420 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706633329; cv=none; b=VM1NB2Y7UDFchia8ZM6unCUqlSDbx0FRdObKULRNR4oCUL4xIyM2SiLHuJlkeY36z0fHHEc6hzMqOwaja7Ro++1YmIQIWCCK04i/5MwDu1XZDlPxtnFjVhcphnQ9BmUdkeL9NJy2HDg4X1/ltxJ9jGjLtyvxkXgEMbmuEV4a5ZY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706633329; c=relaxed/simple; bh=Ne4oLC0jaaRRkCK0uruqNt0IDVAInHCQCrx/LjY4uFA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=XcR109X20EzD9m/EP7+ShTdbwLSUpuLmTTIo/jCNm2ZUp6+Axof+lfaOt/4tRhgJiancej1igPTkXhBTM0HpA3AZC97hioJbYnGxr/AW61B04cnzBtK/A9XeyVmTwrgRyDaD4Yxo2oUzSV6/PTRID64QCx4F0Ah52R9hSgEo90s= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1706633328; 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=xRU48Hx8lcqLlQRyP7K2hzVJrcp/+UFkQ+dJL3/x8g4=; b=Mf77Jk8LBorc8Y2iQ5kXFJvkF9i4R6eeMGAMxHoTu8rL/ba7CuBiqU8lnAU+Mt5nVSbG07 8/atFsgSgzBR4UOznXKCgjlhZnQ93/W8mjGqlipDbzXf3WzmRNai/f3Y6W9H9PAhKkLEpl OIe3DAh62gcGRhLj/vkcj0rUDG41Z9w= Received: from mail-lf1-f70.google.com (mail-lf1-f70.google.com [209.85.167.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-401-c3AOWYkzM0KvyUL7NpCY6Q-1; Tue, 30 Jan 2024 11:48:46 -0500 X-MC-Unique: c3AOWYkzM0KvyUL7NpCY6Q-1 Received: by mail-lf1-f70.google.com with SMTP id 2adb3069b0e04-5100d033f56so3293254e87.0 for ; Tue, 30 Jan 2024 08:48:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706633324; x=1707238124; 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=xRU48Hx8lcqLlQRyP7K2hzVJrcp/+UFkQ+dJL3/x8g4=; b=PbKp3UpcxGJfNYuA1W4xLepFhBbeBCslocPg5xHAZgycjOS6WqXaptjR6Q8ZG/DJeL dMK6JyO2DuGkkCfsqhgylDg1HfILVsnGqehZVwPxirwl3R3smRN4BltcOgqNGnDCR0zJ hHemmyXmBbQxOcgT1AS/xUZuwLLp5q4be2SsTrcI+xOq/xeDYmS8/jD0raHXG8gcYnLg F3ECNLI4lcMaVU7xm/aoceHR0umL3VLYena3k0BQTp26RhCVZmKAp+ZJ92XFTAkAkHgv LmeOoJ00dhI0nEor6YLzRdGHM6u2ufGSQikmCpJyCM4j+5/KnWE/9pdY9gRvB8YDmKQZ +7vA== X-Gm-Message-State: AOJu0YyHj4lzIy6zD16ckcFmZSfbyDhsc+rgKIITmJFtzUTF7dsbV6PM yJHkCiKGA2E7V1WzB9i1w5IXoigrauSdoxwBJDL4/PWjlARCKhtWKcch/hN+hgSxFv0Zh0qdDig TS5HLcvQJ1K75DMlWGGIgD7NPH3I1p0WQdTyJJV45HLKbrb6fT8LYhuxgs5vo7xj/l0o= X-Received: by 2002:a05:6512:3b0e:b0:50e:7a91:7e93 with SMTP id f14-20020a0565123b0e00b0050e7a917e93mr7637537lfv.44.1706633324310; Tue, 30 Jan 2024 08:48:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IF2rLcDVRD6NM/z5e68yeeKb5H78R/fe6BPTPjL/FEQJ8fAXXHlNelzvkcUb2230l6bR9gsbA== X-Received: by 2002:a05:6512:3b0e:b0:50e:7a91:7e93 with SMTP id f14-20020a0565123b0e00b0050e7a917e93mr7637515lfv.44.1706633323829; Tue, 30 Jan 2024 08:48: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 fa8-20020a056000258800b0033afb7c68a7sm2123385wrb.55.2024.01.30.08.48.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jan 2024 08:48:43 -0800 (PST) Message-ID: <08392c1c-41e4-4011-aa68-a8d6c6321556@redhat.com> Date: Tue, 30 Jan 2024 17:48: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> From: Guinevere Larsen In-Reply-To: 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_H4,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 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. Or I could also just try the simple try-catch I alluded to above and leave the scope creep to a future patch, I guess.... > > (I would look into it, but I don't really have the time right now.) > > If you agree with this, then perhaps you can keep the expected output > in the test (we would have to determine which output makes more sense), > but XFAIL the case that doesn't work as we want today. At least, that > will leave a trace that something needs to be fixed. I fear that by > just accepting .*, it will just get forgotten. Sure, I'll swap this patch to an XFAIL in that case for v2 -- Cheers, Guinevere Larsen She/Her/Hers > > Simon >