From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by sourceware.org (Postfix) with ESMTPS id 35C5A385AE75 for ; Mon, 13 Jun 2022 13:54:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 35C5A385AE75 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f51.google.com with SMTP id o8so7249018wro.3 for ; Mon, 13 Jun 2022 06:54:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=PYOzvZE65e9Va6Zyn52SzWnp903LYpWlcLN1pI3q7Tw=; b=wwmVAAw6piGULluE2+85qVupxNyoEmLSPeg8rMGaVF6T2ajCSg3cLaEzuMPWtuLuty jQui8nFCdey8Ox/JSJaNviWx6XLD1mNErwEfrqNByUrvFbMIi1FrutHhkTDOSkKRKIJT weVOpPWnJHDskl6YEUKZTZl6RiewtY16tudbwcVKSu3z8em+MiowqkQ/8+Oh+7vg0rXw cr4A/ryxxd7kB7jOmgPRPh95/36pIYG24hYLrGldIz0uYqySAMXORsAQNX0reEh1+gig rRWXkbPkuf5hAAZDsreUFx7ocfRw+MEKnr5Wcgnrq0WRxjqVDz8MWtEw8Js3fy8RsSzf S6Sg== X-Gm-Message-State: AJIora+RXUVB135yiwydZtokv56TwtwrG+BOd7RNNheBZPCwrdeeuozE qRBOqybbK/i08deq6idR4ea7nY6sup8= X-Google-Smtp-Source: AGRyM1tBfIlNweJvOcu0pDQ1Mg8xslKPvCX9Jma+F6BCrgDUUX8od+xU94j00a5sjEXJVfKFb8xyYQ== X-Received: by 2002:adf:e350:0:b0:21a:3bc:7d85 with SMTP id n16-20020adfe350000000b0021a03bc7d85mr14846wrj.400.1655128467704; Mon, 13 Jun 2022 06:54:27 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id k4-20020a05600c1c8400b003971fc23185sm14611922wms.20.2022.06.13.06.54.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jun 2022 06:54:26 -0700 (PDT) Message-ID: Date: Mon, 13 Jun 2022 14:54:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH] Debug support for global alias variable Content-Language: en-US To: "Natarajan, Kavitha" , Tom Tromey , "Natarajan, Kavitha via Gdb-patches" Cc: "George, Jini Susan" , "Parasuraman, Hariharan" References: <87ilra1gcx.fsf@tromey.com> <87sfqawi0v.fsf@tromey.com> <871qxsisr7.fsf@tromey.com> <498102ba-9a88-5ca7-ebe7-7120b655ee9c@palves.net> <41b119d8-0321-23de-212b-33a328720455@palves.net> <26e8bc61-4833-e4f2-5938-d2ba52a8e3cb@palves.net> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2022 13:54:34 -0000 On 2022-06-13 12:11, Natarajan, Kavitha wrote: >>>> +gdb_test "p g_def_var" " = 2" >>>> +gdb_test_multiple "p g_def_var_alias" "print alias of deferred variable" { >>>> + -re -wrap " = 2" { >>>> + pass $gdb_test_name >>>> + } >>>> + -re -wrap "has unknown type; cast it to its declared type" { >>>> + if { $using_clang } { >> >> So all other tests pass with your fixed Clang, but this one will still xfail. >> Do you have more information about this? Strange offhand that "alias of >> alias" works, but this one doesn't. Is there some Clang bug open about this >> we could add a reference to here? If not, could one be created? If instead >> you think this is a GDB bug, then this should be a kfail ("known gdb fail") >> instead of an xfail, in which case we should have a bug open in gdb's bugzilla >> about it so we can reference it here. > > This is a clang bug. For the alias of deferred declaration, clang does not generate > debug information. Clang has to emit the DIE with DW_TAG_imported_declaration tag. > So, this is an expected failure. I can add a comment for the xfail part. > Alright, thanks for the clarification. >>>> +extern int g_def_var_alias __attribute__ ((alias ("g_def_var"))); >>>> + >>>> +int g_def_var = 2; >>>> + >>>> +extern int g_def_var2_alias __attribute__ ((alias ("g_def_var2"))); >>>> + >>>> +int g_def_var2 = 3; >> >> Offhand, there doesn't seem to be any difference between g_def_var_alias >> and g_def_var2_alias? If we really need both, then I'm thinking this could >> use some comment. > > Yes, they are same. I just wanted to call out the xfail through g_def_var_alias that > no debug information is generated when the aliasee is declared later. In case of > g_def_var2_alias, though its aliasee is declared later, the debug info is generated > (as DW_TAG_variable) when g_def_var2_alias2 accesses it to generate its debug info. > When I am writing this, I am thinking of removing this xfail part itself. Anyway, > g_def_var2_alias would cover the same case when clang is fixed. OK. With these explanations, it's clearer. I think keeping the xfail test was OK too, it just needed a comment. But this is fine with me as is. Just the "using_clang" variable is no longer used, so should be removed. Do you have write access, or do you need someone to push your patch?