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 61C723858439 for ; Tue, 16 May 2023 09:41:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 61C723858439 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1684230116; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xFl7ZAVx+6MCtb+eEHtUXOolnhaucrZ1KkWyyn/8tEQ=; b=eJc9SgJ5vw9cFxvsqx661CAX/OdalbiuTaT7yAEab4sKY+8Zv0sHjrJPeCZeLRbQJ7K3Ue JUKXt39m+FmSV0PZz+7MOF2ttkI9JgW8WTW/ykk/blbVREaeUJ4au4jQZ/mcZTjp8ENUqN Oncmwk0L5eV2MgMkAlsqIOzjtf2SLIs= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-170-cf4ovAXXOEO7-E2w3koyTA-1; Tue, 16 May 2023 05:41:54 -0400 X-MC-Unique: cf4ovAXXOEO7-E2w3koyTA-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-30620ebd3c2so8736693f8f.0 for ; Tue, 16 May 2023 02:41:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684230113; x=1686822113; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xFl7ZAVx+6MCtb+eEHtUXOolnhaucrZ1KkWyyn/8tEQ=; b=N3L1UagV0bVWcm4s+KvXlGWbHYMqq2Z9UoBWg9kD2q2wclL2NPpyXiFbVLmyMH0q8c Veoa/uo6zNw7sBSItJ3bLSiISaHyhFYgd3Y+wkcCVaeTeQUQxznm+tGN6Q26fXZzpJB0 o7dJiriBkTHKxx7oJHwC5f+7pjeEFkN+h+EGUHU3bUASjRP0DOmE4gfa54L4QSCRZWcN /PcFQhTiMQOXiTDdLV5mXE3woUt3Y01m2TDYFKZOgPBWQnJ8WG+ZYrQC0NptjkobznqN clvs6OZl+RwBVSFPK0lkvmJStJAty+sAAK88FR73tgm33DHRR/0FtGfl2iNOSQeELCXs yRKQ== X-Gm-Message-State: AC+VfDycjQ099h3S8RGCc6ptrUfqAfYNZJUORGdiD3mcMR2zq8Q/s/E0 EfVa9EDnPU7iYs7pHrvelGvoGAfDNENcPS8JJGv4FcDbL/34Ss9k1+6KKytdrOLcwyCZJeLDVa4 RwhWOwHPxr/QikNF0fMQBZ5viSjnl/Q== X-Received: by 2002:a05:6000:1250:b0:306:266a:2dc8 with SMTP id j16-20020a056000125000b00306266a2dc8mr24892289wrx.64.1684230113242; Tue, 16 May 2023 02:41:53 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5V3sHVsd0XrJOUZt+Q56qA7KdjZNn0nVwIcTPGauKg6bFsRL9qL8LgcvnMM0l3hL1TqOR49A== X-Received: by 2002:a05:6000:1250:b0:306:266a:2dc8 with SMTP id j16-20020a056000125000b00306266a2dc8mr24892275wrx.64.1684230112859; Tue, 16 May 2023 02:41:52 -0700 (PDT) Received: from localhost (11.72.115.87.dyn.plus.net. [87.115.72.11]) by smtp.gmail.com with ESMTPSA id i18-20020a5d5592000000b00307acec258esm2021745wrv.3.2023.05.16.02.41.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 May 2023 02:41:52 -0700 (PDT) From: Andrew Burgess To: Luis Machado , gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/testsuite: fix s390 failure in break-main-file-remove-fail.exp In-Reply-To: <36ee8832-c197-6055-4e62-953f8769f84c@arm.com> References: <36ee8832-c197-6055-4e62-953f8769f84c@arm.com> Date: Tue, 16 May 2023 10:41:51 +0100 Message-ID: <875y8sbokg.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=-11.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_DNSWL_NONE,RCVD_IN_MSPIKE_H2,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 List-Id: Luis Machado writes: > On 5/15/23 20:38, Andrew Burgess via Gdb-patches wrote: >> After this commit: >> >> commit a68f7e9844208ad8cd498f89b5100084ece7d0f6 >> Date: Tue May 9 10:28:42 2023 +0100 >> >> gdb/testsuite: extend special '^' handling to gdb_test_multiple >> >> buildbot notified me of a regression on s390 in the test: >> >> gdb.base/break-main-file-remove-fail.exp >> >> the failure looks like this: >> >> print /d ((int (*) (void *, size_t)) munmap) (16781312, 4096) >> warning: Error removing breakpoint 0 >> $2 = 0 >> (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "((int (*) (void *, size_t)) munmap) (16781312, 4096)" >> >> The above commit changed get_integer_valueof so that no output is >> expected between the command and the '$2 = 0' line. In this case the >> 'warning: Error removing breakpoint 0' output is causing the >> get_integer_valueof call to fail. >> >> The reason for this warning is that this test deliberately calls >> munmap on a page of the inferior's code. The test is checking that >> GDB can handle the situation where a s/w breakpoint can't be >> removed (due to the page no longer being readable/writable). >> >> The test that is supposed to trigger the warning is later in the test >> script when we delete a breakpoint. >> >> So why does s390 trigger the breakpoint earlier during the inferior >> call? >> >> The s390 target uses AT_ENTRY_POINT as it's strategy for handling >> inferior calls, that is, the trampoline that calls the inferior >> function is places at the program's entry point, e.g. often the _start >> label. >> >> If this location happens to be on the same page as the test script >> unmaps then when the inferior function call returns GDB will not be >> able to remove the temporary breakpoint that is inserted to catch the >> inferior function call returning! As a result we end up seeing the >> warning earlier than expected. >> >> I did wonder if this means I should relax the pattern in >> get_integer_valueof - just accept that there might be additional >> output from GDB which we should ignore. >> >> However, I don't think this the right way to go. With the change in >> a68f7e984420 we are now stricter for GDB emitting warnings, and I >> think that's a good thing. >> >> So, I think, in this case, in order to handle the possible extra >> output, we should implement something like get_integer_valueof >> directly in the gdb.base/break-main-file-remove-fail.exp test script. >> >> After this the test once again passes on s390. >> --- >> .../gdb.base/break-main-file-remove-fail.exp | 17 ++++++++++++++++- >> 1 file changed, 16 insertions(+), 1 deletion(-) >> >> diff --git a/gdb/testsuite/gdb.base/break-main-file-remove-fail.exp b/gdb/testsuite/gdb.base/break-main-file-remove-fail.exp >> index 66ccc60a21a..c7cf4f3df00 100644 >> --- a/gdb/testsuite/gdb.base/break-main-file-remove-fail.exp >> +++ b/gdb/testsuite/gdb.base/break-main-file-remove-fail.exp >> @@ -89,7 +89,22 @@ proc test_remove_bp { initial_load } { >> set align_addr [expr $bp_addr - $bp_addr % $pagesize] >> set munmap_prototype "int (*) (void *, size_t)" >> set munmap_expr "(($munmap_prototype) munmap) ($align_addr, $pagesize)" >> - set munmap [get_integer_valueof $munmap_expr -1] >> + >> + # Use gdb_test_multiple here rather than get_integer_valueof. >> + # Targets that use the AT_ENTRY_POINT strategy for inferior >> + # function calls will place a breakpoint near the entry point >> + # to catch the return from the inferior function call, and >> + # this is likely on the page we are about to unmap. As a >> + # consequence we will see the warning about being unable to >> + # remove the breakpoint here, which throws off >> + # get_integer_valueof. >> + set munmap -1 >> + gdb_test_multiple "print /d ${munmap_expr}" "get result of munmap call" { >> + -re -wrap "^(?:warning: Error removing breakpoint $::decimal\r\n)?\\$\[0-9\]* = (\[-\]*\[0-9\]*).*" { >> + set munmap $expect_out(1,string) >> + pass $gdb_test_name >> + } >> + } >> >> if {$munmap != 0} { >> unsupported "can't munmap foo's page" >> >> base-commit: 6a1cf1bfedbcdb977d9ead3bf6a228360d78cc1b > > Thanks for the patch. I was chasing this one as well, as it also fails > for arm and aarch64. From what I noticed, it also fails for ppc/ppc64. Sorry for introducing the regressions. I've gone ahead and pushed this patch as it was impacting so many targets. If there's any follow up feedback I'm happy to make any additional changes needed. Thanks, Andrew