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 7CEB9385842D for ; Fri, 3 Feb 2023 13:44:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7CEB9385842D 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=1675431880; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uE55ak0EFaPh5/unTgl226Q1YhYhBTazG0nQ+L7w+3s=; b=TtQSnKUq0QkxYRc801ZnnjB7PcXG2SYtamydqgh6jTxs5tmupk2RzUecdSbfu3gvXauPYh BPxVh1/9WBeYpYNi3LGU3v+NlWZ0I7mavpKI/N8RXYCGOZfK2R1Og9AQb1s/Q75qYa7ANz cBDz5qJki2NIQEisNbDPKjft3j189Vc= Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-633-4UbBgXdkPGiI3UDQTHVEDA-1; Fri, 03 Feb 2023 08:44:35 -0500 X-MC-Unique: 4UbBgXdkPGiI3UDQTHVEDA-1 Received: by mail-qt1-f199.google.com with SMTP id bs11-20020ac86f0b000000b003b9b4ec27c4so2612991qtb.19 for ; Fri, 03 Feb 2023 05:44:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=uE55ak0EFaPh5/unTgl226Q1YhYhBTazG0nQ+L7w+3s=; b=YRDKaZiCnb5mfT4D7TLTU6l1wCHmbnjVHqfZFeQU71DRJX0fXkwn6i1rCki2dYpmux d2q+e8YHai/qElwH76sKjIr1dbOPjzNdF1UDymnK9yzfINdrk840L27rxjy3dum64Uq5 GlakKsuURhSxKw7T0K0uKRLQ76sJYC9M006jaxuxcg0s7Z+9n9s5bTulIepeWuSyQF5I N1BCd89ibXnMKB4AO0l4oRqNMblqjyo0MXY/CkmDo9wEkgQtuRkv6XOOTr/vQA56r05L EfbBGve0lFQOABh5fJSjI0tRkbjt1b0rSTT6UR9QMUH53Y5us1YTXZqEWlt2LCz7uKnn NqDA== X-Gm-Message-State: AO0yUKVcVCtNNPgSMyhXvzJBMK/IRYEd+fT8g1hsdQWIC8E3u6IS20Tx KzfqXYBvRfG5ZuMFNa9BHeOapko/xhQMyU5vM+p80F4r8ZgzAq7WoER0gPeiqp3YA1ib47YO7Ds dRNUpyDkb2nLIEVSIyzFFLSniU0NkH7UbHD0pSyp0LcUnkI4jO5vA/VPfslAahRajSIBORW9SfA == X-Received: by 2002:ac8:5f52:0:b0:3b9:bdb0:7aa1 with SMTP id y18-20020ac85f52000000b003b9bdb07aa1mr17180700qta.41.1675431872648; Fri, 03 Feb 2023 05:44:32 -0800 (PST) X-Google-Smtp-Source: AK7set9LQatANvqA/Xg2ztBZMvYyIe51Br23IckG1VuEbsDhJ4Za/oFxKgTv5BMA0fXnToXbI/xRfg== X-Received: by 2002:ac8:5f52:0:b0:3b9:bdb0:7aa1 with SMTP id y18-20020ac85f52000000b003b9bdb07aa1mr17180647qta.41.1675431872208; Fri, 03 Feb 2023 05:44:32 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id k64-20020a37ba43000000b007023fc46b64sm1754345qkf.113.2023.02.03.05.44.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Feb 2023 05:44:31 -0800 (PST) From: Andrew Burgess To: Bruno Larsen via Gdb-patches , gdb-patches@sourceware.org Cc: Bruno Larsen Subject: Re: [PATCH 2/2] gdb/testsuite: fix running gdb.linespec/cp-completion-aliases.exp with clang In-Reply-To: <20230117130007.1686917-3-blarsen@redhat.com> References: <20230117130007.1686917-1-blarsen@redhat.com> <20230117130007.1686917-3-blarsen@redhat.com> Date: Fri, 03 Feb 2023 13:44:30 +0000 Message-ID: <87a61usw1t.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-11.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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: 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. > > 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? 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)" \ +]