From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 783AB3851C28 for ; Thu, 4 Jun 2020 12:18:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 783AB3851C28 Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-371-k8tAYuAAOG2U7wl5xNGNrg-1; Thu, 04 Jun 2020 08:18:06 -0400 X-MC-Unique: k8tAYuAAOG2U7wl5xNGNrg-1 Received: by mail-wm1-f71.google.com with SMTP id v23so1948668wmj.0 for ; Thu, 04 Jun 2020 05:18:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FUFiB46XzOFzj/I/a+N32O0og9ATfBcTX+0hKz+9nl0=; b=UucmTmFImoDC7gtR6Y8FRxFYF8eJcGK20KfWad+xf8jNEQ2Ya340Tqn8qz7fHqAxwo N4nAKr7a/Zg5a/lXTwc0fr9O32ZvLsof8UiTNRYp90yw6O7LC5CqV9HRxEwRiCT+SNMn R9HltDjJihuWOXDBy3UKAy0vMA/d1CrhBV8R31iAvqdrRbRGO6+aCwgpqnF7XjgcbWuw HNLv7TIQaQOPFIX0AJteFCkDjFAHlOUbq4U6DlbQVV+Cp8uu1fOjpGImbRgyBIylKra0 i2WqBkKkDLCQckhJ/DhGuQ5tQibpevyTVk5z6YwUMK6X0T1xsGu7WCX0Jq7rQRLfbqr/ pltA== X-Gm-Message-State: AOAM532x6Xm9eatDmcR9usA5XiwSP8zFzpduEl+cgTHE9e1btBdNnJx6 hUuYOIl7U+uXHoMrS72aFewljF7Q8WkExpi0yFtEnw6SuPSmGhlLPnnE6IyxPb3ev8O5SHJHHQY jZPQWbRM8KUwBecfjrnI1AQ== X-Received: by 2002:a7b:c090:: with SMTP id r16mr4012763wmh.105.1591273085336; Thu, 04 Jun 2020 05:18:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwgxriJLg1yqY826IsJEtEIcGVDLJLWFlg+yA7C2LVh9kWcpGPFcmcetZLOPh4xCd01BZCmVQ== X-Received: by 2002:a7b:c090:: with SMTP id r16mr4012742wmh.105.1591273085101; Thu, 04 Jun 2020 05:18:05 -0700 (PDT) Received: from ?IPv6:2001:8a0:f922:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f922:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id h12sm7496018wro.80.2020.06.04.05.18.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2020 05:18:04 -0700 (PDT) Subject: Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd To: Tom de Vries , gdb-patches@sourceware.org References: <20200604102423.GA2054@delia> <6e23995a-349d-7c5e-970e-648c3fade47c@suse.de> From: Pedro Alves Message-ID: <1fe127b1-7238-1348-138a-58d8c5fd477d@redhat.com> Date: Thu, 4 Jun 2020 13:18:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6e23995a-349d-7c5e-970e-648c3fade47c@suse.de> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 04 Jun 2020 12:18:10 -0000 On 6/4/20 12:51 PM, Tom de Vries wrote: > On 04-06-2020 13:43, Pedro Alves wrote: >> On 6/4/20 11:24 AM, Tom de Vries wrote: >>> @@ -1800,7 +1801,7 @@ proc gdb_file_cmd { arg } { >>> return -1 >>> } >>> -re "A problem internal to GDB has been detected" { >>> - fail "($arg) (GDB internal error)" >>> + fail "($basename) (GDB internal error)" >>> gdb_internal_error_resync >>> return -1 >>> } >> >> The -re above has the exact same issue in the ERROR call. > > Right, but the PATH detection is only for testnames, not for error messages. That seems like a bug in the PATH detection stuff to me: Running /home/pedro/brno/pedro/gdb/binutils-gdb-2/build/../src/gdb/testsuite/gdb.ada/O2_float_param.exp ... ERROR: (/home/pedro/brno/pedro/gdb/binutils-gdb-2/build/gdb/testsuite/outputs/gdb.ada/O2_float_param/foo) (GDB internal error) This makes is as hard to diff gdb.sum files as a FAIL/PASS with a build path. > >> I have no idea why this one is a fail while everywhere else >> in the procedure perror is used. Seems inconsistent. > > It is locally inconsistent indeed, but it is consistent with all other > handling of "A problem internal to GDB has been detected" in gdb.exp. If you look at those other spots, they are using fail/pass in the other surrounding -re's, and thus that's just another fail among all those. I.e., those cases are internally consistent. Like e.g.: -re "${sentinel}" { fail "${test} (pattern ${index} + sentinel)" set ok 0 } -re ".*A problem internal to GDB has been detected" { fail "${test} (GDB internal error)" set ok 0 gdb_internal_error_resync } timeout { fail "${test} (pattern ${index} + sentinel) (timeout)" set ok 0 } The gdb_file_cmd one started out with a message string that didn't even include the parens around the "GDB internal error" string in 04e7407c59a: + -re "A problem internal to GDB has been detected" { + fail "($arg) GDB internal error" + gdb_internal_error_resync + return -1 + } The parens were later added in 5b7d00507b9: -re "A problem internal to GDB has been detected" { - fail "($arg) GDB internal error" + fail "($arg) (GDB internal error)" Arguably that patch should have switched to perror instead. A FAIL message with only text wrapped in parens is odd, since the trailing "(foo)" text is not supposed to count as test message. So in effect, you could say that this fail has no test message, the same as if you wrote: fail "" Pedro Alves