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 50F403858D1E for ; Mon, 6 Feb 2023 15:48:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 50F403858D1E 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=1675698528; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tmJ48SBbkUAQCY+xBZUH15BaMWizWKuLlu09rPz1hWM=; b=BBl6nMgZT9cSmP74MIVxcZ0e3AE7asyAfr6BDXkMDOUQWOWoPREMbstBzjw+pIz2/NwpL4 GyUjzbvh3JjqLo8k/2GXuQR1QmfsfSbMdLyBW0tE1VRZx35FxTxOUnxGnefU87gSlXj2Jy J/9s3oe0EgpvZ3NKMNw+dmuuHK91iDU= 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-35-JCMUjFawO_2qo0GLYFKc1w-1; Mon, 06 Feb 2023 10:48:47 -0500 X-MC-Unique: JCMUjFawO_2qo0GLYFKc1w-1 Received: by mail-qt1-f199.google.com with SMTP id t5-20020a05622a180500b003b9c03cd525so6789974qtc.20 for ; Mon, 06 Feb 2023 07:48:47 -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:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tmJ48SBbkUAQCY+xBZUH15BaMWizWKuLlu09rPz1hWM=; b=swac1uRGj3Oq+3384BHDF6Zln2fmJqCz6LEO+I6k6b5YB6daX1poT4S5Oe+/wGwiIt JbjFoixIW75u1RKV9B/9clIgyaKfl+ERA0a6xOQmeKNyzRmqu7v/Wq8NGfZZMXTzZIOM hRxVpLRK/OSHsp7QkL+XNJahrp9w9Al0f89Lt/J2MdOMqQZ44AuxDRAo67tyR7GVBa26 35saJBv7yZVKVqU72gejW7WpU+rgSSe51in0RQ5BDnV7J4sdYwkAlM2/sLtsUZLnp/UQ bzSYtD6EakVftyPlDYM9V5SNvlB/dwN6asxZn9tlul/bGxut1OkiVy9PZHaj5xzACERH 32XA== X-Gm-Message-State: AO0yUKVPcn6Jhesq5c8hWXh80yKiDMkaF5YKuwf0hsAbnu4Er/rv4r2p 4m4JTuoU/tKHBj7W+mrcAXrEbVJeJjkG1YK1NkXZVxySaPGFpHOwyOkafFuvpbHuPOwjE2BV+uo XzIqj4B7VNaoDMke6ZScXzg== X-Received: by 2002:a05:622a:1449:b0:3b6:313a:e27a with SMTP id v9-20020a05622a144900b003b6313ae27amr33557003qtx.40.1675698527223; Mon, 06 Feb 2023 07:48:47 -0800 (PST) X-Google-Smtp-Source: AK7set8pCLyauVWhVIgrLWGvlx+aILmo9arEByc+B5Di3yz518Fp77W3jtnamIQhKfZqbbyrdiQ6AA== X-Received: by 2002:a05:622a:1449:b0:3b6:313a:e27a with SMTP id v9-20020a05622a144900b003b6313ae27amr33556980qtx.40.1675698526839; Mon, 06 Feb 2023 07:48:46 -0800 (PST) Received: from localhost (95.72.115.87.dyn.plus.net. [87.115.72.95]) by smtp.gmail.com with ESMTPSA id fz14-20020a05622a5a8e00b003b9e1d3a502sm7450944qtb.54.2023.02.06.07.48.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Feb 2023 07:48:46 -0800 (PST) From: Andrew Burgess To: Bruno Larsen , Bruno Larsen via Gdb-patches Subject: Re: [PATCH 2/2] gdb/testsuite: fix running gdb.linespec/cp-completion-aliases.exp with clang In-Reply-To: <0fcb850d-4b9a-a549-994c-f9c8d744753d@redhat.com> References: <20230117130007.1686917-1-blarsen@redhat.com> <20230117130007.1686917-3-blarsen@redhat.com> <87a61usw1t.fsf@redhat.com> <0fcb850d-4b9a-a549-994c-f9c8d744753d@redhat.com> Date: Mon, 06 Feb 2023 15:48:45 +0000 Message-ID: <878rhax09u.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.7 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 writes: > 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. Having thought about this more since I posted, I feel that we should try to fix how GDB displays the functions for the Clang compiled binary. My feeling now is that GDB is just getting it wrong in the Clang case. I guess we would need to dig into those 200 regressions and see what's actually going on there. > 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. I'd hold off until we have a use case for it. I think if we fix up how GDB handle Clang then we'll have no use case for now. Thanks, Andrew > >> >> 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