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 EAF2E3858D1E for ; Mon, 6 Feb 2023 14:10:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EAF2E3858D1E 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=1675692621; 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=Nd7fZEHRq/65NdhuMnWKxcu0ymzsME0Fp8n3Lm2/Iq0=; b=cjojY2jOYNLFJQAEFxFxgfMWpauBT3xck5mpt2eNzFL/rmLRYXe82KCvoeYUNF9ivEkGur DQVqNbL2afWjoVZMZ7wvUdz9gErGpAMLzHbzK5CyY/xuusoUm1nRcJNnCW4W3pomfgUUFA VvvDBPJLi0uNh3g21ALlbFlUNab5EDE= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-26-TUrH-2u3Mrytd09MIkjkbA-1; Mon, 06 Feb 2023 09:10:20 -0500 X-MC-Unique: TUrH-2u3Mrytd09MIkjkbA-1 Received: by mail-qk1-f199.google.com with SMTP id v7-20020a05620a0f0700b006faffce43b2so7783213qkl.9 for ; Mon, 06 Feb 2023 06:10:20 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Nd7fZEHRq/65NdhuMnWKxcu0ymzsME0Fp8n3Lm2/Iq0=; b=W3m2PoV37wuHctNTvLLSws0F5n8DeUUTEhKiIEd5l2/jl/na3fkhghKuoO9K7LXZ8V 92xR4MCAIMTdUCexYlVUie5of1+zvCfq+tYtrBLZcL2p1pspMX9eSIYqE2Q6HyjWa7iE ln4D/c4R4b46pnCeu9Xc5dSk95xrwI4Be/Bg6SejqbsyhoIgfmSWYcnk4wvYSYy84CMJ CuPDpshzgt05vnezE8Ke2Hd62wYPvSnqQ9rYFKISY/Q/64HJKPrKfMmmYyVF8B3DA4tK 2vuP2wX4Vv4r1OIOwCrmC+0ktE0gLtm9BMHIJUf2s0w/8Kjy/GnpKcf9uPoK/SFJKNO7 kW6A== X-Gm-Message-State: AO0yUKVw74H+PgZdeiJ6uqr+v6dhS50+OssW2medc+dcvbwJc+ckGaNP F9gpm9SnFoPP+Nn9HG60UekWwcePc5yvRJ6tphiVIa3hGZYwSWs2WsHASRTeJ96axsfFZL/sE6J b0lpbg/aSkrsuWR6njGonJw== X-Received: by 2002:ac8:7d45:0:b0:3b8:48e4:83b1 with SMTP id h5-20020ac87d45000000b003b848e483b1mr37224283qtb.20.1675692618209; Mon, 06 Feb 2023 06:10:18 -0800 (PST) X-Google-Smtp-Source: AK7set92YgagDjNNyMzzlbStWuwEPyRs8tIgrsz3RuiwbIbRKuQcaSziibZI8blD39/Oecj8vbp4PQ== X-Received: by 2002:ac8:7d45:0:b0:3b8:48e4:83b1 with SMTP id h5-20020ac87d45000000b003b848e483b1mr37224252qtb.20.1675692617888; Mon, 06 Feb 2023 06:10:17 -0800 (PST) Received: from [192.168.0.45] (ip-94-112-225-44.bb.vodafone.cz. [94.112.225.44]) by smtp.gmail.com with ESMTPSA id c11-20020a05620a164b00b0071c9bf854c6sm7334483qko.69.2023.02.06.06.10.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Feb 2023 06:10:17 -0800 (PST) Message-ID: <0fcb850d-4b9a-a549-994c-f9c8d744753d@redhat.com> Date: Mon, 6 Feb 2023 15:10:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH 2/2] gdb/testsuite: fix running gdb.linespec/cp-completion-aliases.exp with clang To: Andrew Burgess , Bruno Larsen via Gdb-patches References: <20230117130007.1686917-1-blarsen@redhat.com> <20230117130007.1686917-3-blarsen@redhat.com> <87a61usw1t.fsf@redhat.com> From: Bruno Larsen In-Reply-To: <87a61usw1t.fsf@redhat.com> 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=-11.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,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: On 03/02/2023 14:44, Andrew Burgess wrote: > Bruno Larsen via Gdb-patches writes: > >> Currently, all important tests in gdb.linespec/cp-completion-aliases.exp >> are failing when using clang because the wrong type is being suggested >> for the completion. For example, running with gcc and clang we get the >> following output respectively: >> >> (gdb) break get_value(object_p) <- gcc version >> (gdb) break get_value(object*) <- clang version > You are correct that what we print for Clang is not wrong. But I don't > think it's as correct as what we print for GCC. The user wrote > object_p, and the DWARF does encode the object_p for both versions. > It's just in the Clang case there's an extra DW_AT_linkage_name which > seems to send GDB off doing the "wrong" thing. > > I wonder how hard it would actually be to "fix" this so that we print > object_p for Clang? I think it would be helpful to really understand at > which point we diverge when comparing Clang and GCC binaries. I took a look at the next patch you sent, but it introduced over 200 regressions, I will take a look at solving this later. > >> Since both suggestions are acceptable on their own, and the original bug >> was if GDB suggested both at the same time, this commit updates the test >> to accept both, gcc's and clang's outputs. > On the content of this patch though... > > I think we can achieve the same results without adding anything from > patch #1 in this series. My idea would be to just ask GDB what it's > going to print using 'info functions', then we can expect exactly the > right strings. The patch below implements this idea. > > What do you think? This idea sounds good. Would you like this changed even if the clang output is fixed? I can send a patch for it before looking further into how to change GDB's output. Also, do you think the first patch should be abandoned? I feel like it would be a good addition even if we eventually drop my change, but I can drop it if you disagree. > > Thanks, > Andrew > > --- > > diff --git a/gdb/testsuite/gdb.linespec/cp-completion-aliases.exp b/gdb/testsuite/gdb.linespec/cp-completion-aliases.exp > index 33ad72e6f05..342359ea6e1 100644 > --- a/gdb/testsuite/gdb.linespec/cp-completion-aliases.exp > +++ b/gdb/testsuite/gdb.linespec/cp-completion-aliases.exp > @@ -24,18 +24,67 @@ if {[prepare_for_testing "failed to prepare" $testfile $srcfile {debug}]} { > return -1 > } > > +# Clang adds a DW_AT_linkage_name to the DW_TAG_subprogram entry, > +# which results in GDB showing the underlying type names for the > +# arguments, rather than the typedef names. > +# > +# In contrast, GCC doesn't include the DW_AT_linkage_name, and so GDB > +# shows the type name aliases instead. > +# > +# To figure out which we expect to see in the tab-completion output, > +# use 'info functions' output. Look for the functions we care about, > +# and build a dictionary mapping line number to the argument type. > +set types_dict [dict create] > +foreach_with_prefix name {get_something grab_it get_value} { > + gdb_test_multiple "info function $name" "" { > + -re "^($::decimal):\\s+static int $name\\((\[^)\]+)\\);\r\n" { > + set linum $expect_out(1,string) > + set type $expect_out(2,string) > + dict set types_dict $linum $type > + exp_continue > + } > + > + -re "^\[^0-9\]\[^\r\n\]+\r\n" { > + exp_continue > + } > + > + -re "^\\s*\r\n" { > + exp_continue > + } > + > + -re "^$::gdb_prompt $" { > + pass $gdb_test_name > + } > + } > +} > + > +# Now look in the dictionary we built above to figure out how GDB will > +# display the types for different arguments. > +set linum [gdb_get_line_number "get_value (object_p obj)"] > +set object_pattern [dict get $types_dict $linum] > + > +set linum [gdb_get_line_number "grab_it (int_magic_t *var)"] > +set magic_pattern [dict get $types_dict $linum] > + > +set linum [gdb_get_line_number "get_something (my_string_t msg)"] > +set string_pattern [dict get $types_dict $linum] > + > +# Restart GDB, just in case the function lookup above in someway > +# impacted what tab-completion results we might return. > +clean_restart $binfile > + > # Disable the completion limit for the whole testcase. > gdb_test_no_output "set max-completions unlimited" > > test_gdb_complete_unique \ > "break get_v" \ > - "break get_value(object_p)" > + "break get_value($object_pattern)" > > test_gdb_complete_unique \ > "break gr" \ > - "break grab_it(int_magic_t*)" > + "break grab_it($magic_pattern)" > > -test_gdb_complete_multiple "break " "get_som" "ething(" { > - "get_something(my_string_t)" > - "get_something(object_p)" > -} > +test_gdb_complete_multiple "break " "get_som" "ething(" [list \ > + "get_something($string_pattern)" \ > + "get_something($object_pattern)" \ > +] > -- Cheers, Bruno