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 E03EC3858CDA for ; Mon, 12 Sep 2022 10:58:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E03EC3858CDA Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-644-pu59uqIOPDu8PoJty2LdhQ-1; Mon, 12 Sep 2022 06:58:42 -0400 X-MC-Unique: pu59uqIOPDu8PoJty2LdhQ-1 Received: by mail-wr1-f72.google.com with SMTP id v15-20020adf8b4f000000b002285ec61b3aso1478612wra.6 for ; Mon, 12 Sep 2022 03:58:42 -0700 (PDT) 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; bh=63Wm02dDHrSZWc0v2y6sGXlTxz5Vg31wdidIn6CbhJM=; b=V146tCakwRlLFhoyzsxEC/vvdKi24zhWdxW3INrQA9Y5v5jGzoIo6TCTBdxjAL4Fiu mYg3zYvL+n4buNboZYw2o61qclcO6sehR7Jb87lpVWNSi2rglGsDtzhWAhNx65XfZ7ug b6Vpw5pxdKufAFpLXnDYZGlZZC5ElFxpT8EqqtyEZUfpNOBBtoXU8YBudxBn/j7evgOw Llguh0S9Xf0bolUMqyBI1EsRW4MpPGJbx1AH6OBWoOiB97rj0LpHqw5xFFGGmC9avLX8 Sz/l2OaWx1w36WWMInGpuZf6dz8B4o+/GzX5udltnhuIOVf8ZiFlwvSsy6bVk5ieHZwr Pnyw== X-Gm-Message-State: ACgBeo1T0+lRv39aGwO4qZCmNWj5FgFrTA8a0erlSlpfCDwINWuaIS1J 8rtvQG0iCgPYd0bZdWzq6gTLCPVag7BywBznkNgiYKvnCD8zgSQxHsbfELJ3zenECnsUSgBmODT XqcLzq1nPPZms08jwzeMgnA== X-Received: by 2002:a5d:6d03:0:b0:22a:4509:2143 with SMTP id e3-20020a5d6d03000000b0022a45092143mr6912777wrq.185.1662980321206; Mon, 12 Sep 2022 03:58:41 -0700 (PDT) X-Google-Smtp-Source: AA6agR4MZA2YdR1cQW7XaUvaukWbbsW/R179EsVsviWF2ja6iomqe6rx3xTmpeE4kbBg5Z/HuHDwUg== X-Received: by 2002:a5d:6d03:0:b0:22a:4509:2143 with SMTP id e3-20020a5d6d03000000b0022a45092143mr6912767wrq.185.1662980320998; Mon, 12 Sep 2022 03:58:40 -0700 (PDT) Received: from localhost (52.72.115.87.dyn.plus.net. [87.115.72.52]) by smtp.gmail.com with ESMTPSA id w10-20020a05600c038a00b003b2878b9e0dsm9265496wmd.20.2022.09.12.03.58.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Sep 2022 03:58:40 -0700 (PDT) From: Andrew Burgess To: Bruno Larsen , gdb-patches@sourceware.org Subject: Re: [PATCH v4 09/15] gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang In-Reply-To: <20220720194441.168906-11-blarsen@redhat.com> References: <20220720194441.168906-1-blarsen@redhat.com> <20220720194441.168906-11-blarsen@redhat.com> Date: Mon, 12 Sep 2022 11:58:39 +0100 Message-ID: <87h71cluzk.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=-10.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_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, 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, 12 Sep 2022 10:58:45 -0000 Bruno Larsen via Gdb-patches writes: > Because Clang's -O0 is not as unoptimized as gcc's, one of the functions > of gdb.base/msym-bp-shl was being optimized away, making the entire test > fail. A lot of the test fail like so: > > (gdb) break foo > Breakpoint 1 at 0x401030 > (gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo > info breakpoint > Num Type Disp Enb Address What > 1 breakpoint keep y 0x0000000000401030 > (gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint > > As the test expects 2 breakpoints to be placed. This can't be easily fixed > by adding __attribute__ ((used)) to the function, since Clang will still > optimize away the function. Because of this, the test is skipped when > the it detects that Clang is being used In this mail: https://sourceware.org/pipermail/gdb-patches/2022-March/187197.html Pedro suggests using __attribute__((used)), in your follow up: https://sourceware.org/pipermail/gdb-patches/2022-March/187199.html you confirm that this approach works for you. I just checked, and the attribute patch Pedro suggests makes the test pass for me with Clang. Should this patch have been updated? If not, what changed? Thanks, Andrew > --- > gdb/testsuite/gdb.base/msym-bp-shl.exp | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/gdb/testsuite/gdb.base/msym-bp-shl.exp b/gdb/testsuite/gdb.base/msym-bp-shl.exp > index 42adcb191dd..dd7d05bab52 100644 > --- a/gdb/testsuite/gdb.base/msym-bp-shl.exp > +++ b/gdb/testsuite/gdb.base/msym-bp-shl.exp > @@ -22,6 +22,14 @@ if {[skip_shlib_tests]} { > return 0 > } > > +# Clang will optimize away the static foo, regardless of using > +# __attribute__((used)), so we'll always get a single breakpoint > +# making this test useless > +if {[test_compiler_info {clang-*-*}]} { > + untested "Clang optimizes away one of the functions" > + return > +} > + > standard_testfile msym-bp-shl-main.c msym-bp-shl-main-2.c msym-bp-shl-lib.c > set srcfile ${srcdir}/${subdir}/${srcfile} > set srcfile2 ${srcdir}/${subdir}/${srcfile2} > -- > 2.31.1