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 57F173857004 for ; Mon, 12 Sep 2022 12:54:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 57F173857004 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-482-ar-ivGoBND2H71cO5WYj_A-1; Mon, 12 Sep 2022 08:54:13 -0400 X-MC-Unique: ar-ivGoBND2H71cO5WYj_A-1 Received: by mail-wr1-f72.google.com with SMTP id d11-20020adfc08b000000b002207555c1f6so1590420wrf.7 for ; Mon, 12 Sep 2022 05:54:13 -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=omoqhsRApNA8nlnxYnMtmF3ixUPwfr+MvPxzEqE6WzM=; b=tYIkKwxptMAON+oEDsaRbeeznp9fPba9tzuWrICU7Uxh9IfBbWMRSJ2exFpZXeqcZU XNfhmKW3/KFvaqeJnGITXFNjoZS57vBmBudeP5Qj6cXHJ0V+t/BlQ/2CMYREiYOE3PjG EJGTO+rE/XeiqRof5lVjKrTzmx4KM07s4DYiiLcUdtKKBuUbkPJW8Blm9shYCZ4VWqcM ccHHo38b9M6pTuAD0hUNQYqLW77hrzDBIuRLsJkOeFRoEbnhAD8vtRbEXM52wbmWPgIA oLH55MrkRW1OTdI60+bs7xi4GOctJR5Nove09LIqnKvWhsHGt2BZoJMSosikfFGNsJm0 3LEQ== X-Gm-Message-State: ACgBeo382acGSERK6ddWMnoWpwzsYVg71f2Y5F2nCg+DhW6EiIIyrmut sUMbeYdRzULvOAg79uLimoh/ytNmQ8VF3jgn+ZEDjUsuCULatcGEGuoS+rd73//NiFBvEF2UfKN eNaw35TMkQnP1sJhGS7p1rQ== X-Received: by 2002:a05:6000:154e:b0:22a:3177:1985 with SMTP id 14-20020a056000154e00b0022a31771985mr11514739wry.117.1662987252314; Mon, 12 Sep 2022 05:54:12 -0700 (PDT) X-Google-Smtp-Source: AA6agR6oG605DA/hnjNPWGHKDVlUWmC/YeEBgCxB6kS7iPbNeafFhE8WpbLMmsdtfClC1NC76R91GA== X-Received: by 2002:a05:6000:154e:b0:22a:3177:1985 with SMTP id 14-20020a056000154e00b0022a31771985mr11514731wry.117.1662987252103; Mon, 12 Sep 2022 05:54:12 -0700 (PDT) Received: from localhost (52.72.115.87.dyn.plus.net. [87.115.72.52]) by smtp.gmail.com with ESMTPSA id l10-20020adfe58a000000b0022863395912sm7205809wrm.53.2022.09.12.05.54.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Sep 2022 05:54:11 -0700 (PDT) From: Andrew Burgess To: Bruno Larsen , gdb-patches@sourceware.org Subject: Re: [PATCH v4 12/15] [gdb/testsuite]: fix gdb.base/jit-elf.exp when testing with clang In-Reply-To: <20220720194441.168906-14-blarsen@redhat.com> References: <20220720194441.168906-1-blarsen@redhat.com> <20220720194441.168906-14-blarsen@redhat.com> Date: Mon, 12 Sep 2022 13:54:10 +0100 Message-ID: <878rmolpn1.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 12:54:16 -0000 Bruno Larsen via Gdb-patches writes: > When using clang as the compiler for the target, gdb.base/jit-elf.exp > was failing with the following output: > > (gdb) attach 3674146 > Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146 > Reading symbols from /lib64/libm.so.6... > Reading symbols from .gnu_debugdata for /lib64/libm.so.6... > (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6) > Reading symbols from /lib64/libc.so.6... > (No debugging symbols found in /lib64/libc.so.6) > Reading symbols from /lib64/ld-linux-x86-64.so.2... > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > 0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118 > 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */ > (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach > > While gcc's output is as follows: > > (gdb) attach 3592961 > Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961 > Reading symbols from /lib64/libm.so.6... > Reading symbols from .gnu_debugdata for /lib64/libm.so.6... > (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6) > Reading symbols from /lib64/libc.so.6... > (No debugging symbols found in /lib64/libc.so.6) > Reading symbols from /lib64/ld-linux-x86-64.so.2... > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118 > 118| WAIT_FOR_GDB; i = 0; /* gdb break here 1 */ > (gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach > > Clang-compiled code is clearly working, as gdb is attaching and running > to the established breakpoint. I think it would be helpful if you could point out exactly what _is_ causing the failure, see below for why... > To fix the false positive, the regexp for > checking where gdb has stopped was relaxed a little, to allow for the > address at the start of the line, and to allow the relative path. > --- > gdb/testsuite/gdb.base/jit-elf.exp | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gdb/testsuite/gdb.base/jit-elf.exp b/gdb/testsuite/gdb.base/jit-elf.exp > index 38d541f74b9..0f296dfd579 100644 > --- a/gdb/testsuite/gdb.base/jit-elf.exp > +++ b/gdb/testsuite/gdb.base/jit-elf.exp > @@ -54,7 +54,7 @@ proc clean_reattach {} { > clean_restart ${main_binfile} > > if { ![gdb_attach $testpid \ > - -pattern "main.*at .*$::main_srcfile:.*"] } { > + -pattern ".*main.*at .*$::main_basename.c:.*"] } { ... when I run this test using Clang (9.0.1) _without_ this patch, the test passes. I notice that when you ran the test the source file reported at the breakpoint doesn't include the ${srcdir}. I don't know why you're only seeing a relative path, but I guess, as far as this test is concerned, just checking for the final filename is fine. I don't think the change to add the leading '.*' is needed though. The pattern is never anchored to the start of a line, so expect will happily skip any leading content when looking for a match, the extra '.*' is just unnecessary noise. Thanks, Andrew > return 0 > } > > -- > 2.31.1