From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id T1GgAEDqU2LfIgAAWB0awg (envelope-from ) for ; Mon, 11 Apr 2022 04:43:44 -0400 Received: by simark.ca (Postfix, from userid 112) id E15641F202; Mon, 11 Apr 2022 04:43:43 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 333AE1E150 for ; Mon, 11 Apr 2022 04:43:43 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 79E17383D0DD for ; Mon, 11 Apr 2022 08:43:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 79E17383D0DD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1649666622; bh=AYx9a8+KTwnK7LHjIVERyP6KMU4p7egGxScS7UcLSYE=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=g6PugOqUm3BJ9CYhKsmsPLvpJlx9M05LxPqbMvuHvpiOb17pljHpJ2kDBby+u/f5M lFflODsrH++8VzwrZjc8yWidiSP23iY7cn3KvbN1iLYcucKfZOFFkxi/FTj+aEWsCA Qy5aXuTS8unfdG9Q1OqmBCNPOf+kRyEocFHlpg6Y= Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id D27FC385B204 for ; Mon, 11 Apr 2022 08:43:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D27FC385B204 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 13CBA1F37D; Mon, 11 Apr 2022 08:43:21 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F130C13AB5; Mon, 11 Apr 2022 08:43:20 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id QPd4OSjqU2JANAAAMHmgww (envelope-from ); Mon, 11 Apr 2022 08:43:20 +0000 Message-ID: Date: Mon, 11 Apr 2022 10:43:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH][gdb/testsuite] Make gdb.base/annota1.exp more robust Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20220405134732.GA32701@delia> <4a85ab96-c18f-9409-0b8b-68caca2e3e74@suse.de> In-Reply-To: <4a85ab96-c18f-9409-0b8b-68caca2e3e74@suse.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 4/8/22 11:04, Tom de Vries wrote: > On 4/7/22 20:38, Simon Marchi wrote: >> On 2022-04-05 09:47, Tom de Vries via Gdb-patches wrote: >>> Hi, >>> >>> On openSUSE Tumbleweed I run into: >>> ... >>> FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) >>> ... >>> >>> The problem is that the libthread_db message occurs at a location >>> where it's >>> not expected: >>> ... >>> Starting program: outputs/gdb.base/annota1/annota1 ^M >>> ^M >>> ^Z^Zstarting^M >>> ^M >>> ^Z^Zframes-invalid^M >>> [Thread debugging using libthread_db enabled]^M >>> Using host libthread_db library "/lib64/libthread_db.so.1".^M >>> ^M >>> ^Z^Zbreakpoints-invalid^M >>> ^M >>> ... >>> >>> Fix this by making the matching more robust: >>> - rewrite the regexp such that each annotation is on a single line, >>>    starting with \r\n\032\032 and ending with \r\n >>> - add a regexp variable optional_re, that matches all possible optional >>>    output, and use it as a separator in the first part of the regexp >>> >>> Tested on x86_64-linux. >>> >>> Any comments? >>> >>> Thanks, >>> - Tom >> >> Hi Tom, >> >> This introduces a failure on Ubuntu 20.04 and on Arch Linux. >> >>      PASS: gdb.base/annota1.exp: breakpoint info >>      run^M >>      ^M >>      ^Z^Zpost-prompt^M >>      Starting program: >> /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/annota1/annota1 >> ^M >>      ^M >>      ^Z^Zbreakpoints-invalid^M >>      ^M >>      ^Z^Zstarting^M >>      ^M >>      ^Z^Zframes-invalid^M >>      ^M >>      ^Z^Zbreakpoints-invalid^M >>      ^M >>      ^Z^Zbreakpoint 1^M >>      ^M >>      Breakpoint 1, ^M >>      ^Z^Zframe-begin 0 0x555555555183^M >>      ^M >>      ^Z^Zframe-function-name^M >>      main^M >>      ^Z^Zframe-args^M >>       ()^M >>      ^Z^Zframe-source-begin^M >>       at ^M >>      ^Z^Zframe-source-file^M >>      /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/annota1.c^M >>      ^Z^Zframe-source-file-end^M >>      :^M >>      ^Z^Zframe-source-line^M >>      15^M >>      ^Z^Zframe-source-end^M >>      ^M >>      ^M >>      ^Z^Zsource >> /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/annota1.c:15:103:beg:0x555555555183^M >> >>      ^M >>      ^Z^Zframe-end^M >>      ^M >>      ^Z^Zstopped^M >>      ^M >>      ^Z^Zpre-prompt^M >>      (gdb) ^M >>      ^Z^Zprompt^M >>      FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) >> >> The issue is the now hardcoded order of "breakpoints-invalid" and >> "frames-invalid" order in the test regexp, where the output happens in >> the other order.  Before your change, we had: >> >> >> "\(\(\r\n\r\n\032\032frames-invalid\)|\(\r\n\r\n\032\032breakpoints-invalid\)\)*\r\n\r\n" >> \ >> >> Meaning we didn't care about the order of those, and we didn't care if >> we saw them or not.  The change below moves those lines in optional_re, >> and fixes things on my side. >> > > Hi Simon, > > thanks for reporting this. > > I managed to reproduce on openSUSE Leap 15.3 with target board > unix/-pie/-fPIE, and on ubuntu 20.04. > > AFAICT, the issue is not a different order, but an additional > annotation, and looking at the log you've posted above, I see the same. > > I've wrote attached patch which fixes it, I've tested on both openSUSE > and Ubuntu. > > WDYT? Pushed, but now that I reply here I see I didn't fully read the rationale for the patch you posted, and didn't follow up on that, apologies for that. So, perhaps you're right, perhaps we don't care about the order (though it would be nice for me to understand why we don't care). I understood the matching in the test-case to be very loose due to having to juggle mostly the variance in non-annotation output. So I decided to "fix" this by being as strict as possible in matching annotations, and as simple as possible in matching non-annotations. I hope the committed patch will be sufficient though. I you think there's still an issue, then I can revert and apply your patch. Thanks, - Tom