From patchwork Sat Jul 7 10:32:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Burgess X-Patchwork-Id: 28273 Received: (qmail 71331 invoked by alias); 7 Jul 2018 10:33:02 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 71302 invoked by uid 89); 7 Jul 2018 10:33:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.2 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=HX-Received:sk:6-v6mr1, Still, HX-Received:8486 X-HELO: mail-wr1-f46.google.com Received: from mail-wr1-f46.google.com (HELO mail-wr1-f46.google.com) (209.85.221.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 07 Jul 2018 10:33:00 +0000 Received: by mail-wr1-f46.google.com with SMTP id j33-v6so6345362wrj.5 for ; Sat, 07 Jul 2018 03:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=dA76aOUzhW4VXO4JdBMSGhMRKpVaBo6FFBGlfySG5tA=; b=ZaA1fnlRNXohxnjowYYHHGKUrH09dm8/ih50QsFAGaafNoGO0yuT3txPGiDXf1exeK SL1sFX8JOchG5sf7MEDQbl6XDXDv+tMG6EGSGGfeV/laDLHvAUk7ZPLH3ASsrTFXVRa8 H/R/rHZvdCQBrceBAS7zYwZi1JQaGPirq7OGcppxhS20/xYyAgHSdePMAKKLLNWngvn5 OEtYQHf6C/ZTl48Ty6MJGiaHXxv2ZHte4PnX/eGaObMk7tOYVr18WjAKI68nT8/x18qI hHwENLLiq8rSMmSzWoK5ky5dZ+lqJTR+C2MfOjd7Lr4zaLE3GFPdt48P9S1HowN/TeOU U3VQ== Return-Path: Received: from localhost (host86-164-199-62.range86-164.btcentralplus.com. [86.164.199.62]) by smtp.gmail.com with ESMTPSA id w2-v6sm19747278wme.45.2018.07.07.03.32.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 07 Jul 2018 03:32:57 -0700 (PDT) Date: Sat, 7 Jul 2018 11:32:56 +0100 From: Andrew Burgess To: Simon Marchi Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb/testsuite: Allow for failure to read some memory addresses Message-ID: <20180707103256.GS2675@embecosm.com> References: <20180704181302.5364-1-andrew.burgess@embecosm.com> <2cd1d95a-b6fb-3a4d-d07c-5cd9762725e2@simark.ca> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2cd1d95a-b6fb-3a4d-d07c-5cd9762725e2@simark.ca> X-Fortune: An artist should be fit for the best society and keep out of it. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes * Simon Marchi [2018-07-06 22:14:59 -0400]: > On 2018-07-04 02:13 PM, Andrew Burgess wrote: > > In the gdb.base/examine-backward.exp test script, we check to see if > > address zero is readable, and then read memory first forward from > > address zero, and then backward from address zero. > > > > The problem is, being able to read address zero does not guarantee > > that you'll be able to read from the other end of the address space, > > and the test probably shouldn't assume that is the case. > > > > This patch extends the success conditions so that, even if GDB fails > > to read memory, so long as the error message indicates that GDB was > > trying to access the correct location, then we consider this a pass. > > The test is, I think, trying to show that GDB can compute the correct > > address when going backward from zero, being able to access the memory > > at that address is secondary. > > > > One further change is that, when we examined the memory at address > > zero, the regexp used to match the address expected that the zero > > address would have two '0' digits as the least significant digits. As > > GDB strips leading zeros from addresses this was causing the test to > > fail. I've reduced the zero address to a single 0 digit. > > Hi Andrew, > > This probably means that we could run the test even if address 0 is not readable? > On x86_64, I get: > > (gdb) x/3b 0 > 0x0: Cannot access memory at address 0x0 > (gdb) x/-6b > 0xfffffffffffffffb: Cannot access memory at address 0xfffffffffffffffb > > It's not the exact same result as if address 0 is readable (since we didn't > get to read all three bytes in the first command), but it still reaches > the goal of the test. > > > + set test "examine 6 bytes backward" > > + gdb_test_multiple "x/-6x" "$test" { > > + -re "0x\[0-9a-f\]+fd.*:${byte}${byte}${byte}${byte}${byte}${byte}.*\[\r\n\]*$gdb_prompt $" { > > + pass $test > > + } > > + -re "0x\[0-9a-f\]+fd.*:\tCannot access memory at address 0x\[0-9a-f\]+fd.*\[\r\n\]*$gdb_prompt $" { > > + # We test that we can read zero, but that's no > > + # guarantee that we can read from the other end of the > > + # address space. If we get an error about trying to > > + # read from the expected address then we count that as > > + # a pass, GDB did try to read the correct location. > > + pass $test > > + } > > + -re "$gdb_prompt $" { > > + fail $test > > + } > > Is the last stanza necessary? From what I remember, if it doesn't match > any other one, it will already fail the test. Thanks for the feedback. I've updated the test so it now runs more of the tests even when address 0x0 is not readable. I've removed the extra fail conditions, because, as you point out they are covered by gdb_test_multiple anyway. Thanks, Andrew --- [PATCH] gdb/testsuite: Allow for failure to read some memory addresses In the gdb.base/examine-backward.exp test script, we check to see if address zero is readable, and then read memory first forward from address zero, and then backward from address zero. The problem is, being able to read address zero does not guarantee that you'll be able to read from the other end of the address space, and the test probably shouldn't assume that is the case. This patch updates the test script so that even if address zero is known non-readable, we still run the tests, the tests in question are mostly about, can GDB calculate the correct address to read from, we can confirm this even if the final read ultimately fails. We also no longer assume that if address zero is readable, then the other end of the address space will be readable. One further change is that, when we examined the memory at address zero, the regexp used to match the address expected that the zero address would have two '0' digits as the least significant digits. As GDB strips leading zeros from addresses this was causing the test to fail. I've reduced the zero address to a single 0 digit. gdb/testsuite/ChangeLog: * gdb.base/examine-backward.exp: Still run tests around address 0x0, even if address 0x0 is not readable. Update the pattern for matching address 0x0 in expected output. --- gdb/testsuite/ChangeLog | 6 +++ gdb/testsuite/gdb.base/examine-backward.exp | 68 ++++++++++++++++++++++++----- 2 files changed, 62 insertions(+), 12 deletions(-) diff --git a/gdb/testsuite/gdb.base/examine-backward.exp b/gdb/testsuite/gdb.base/examine-backward.exp index be80b841aa8..60e8e254abf 100644 --- a/gdb/testsuite/gdb.base/examine-backward.exp +++ b/gdb/testsuite/gdb.base/examine-backward.exp @@ -83,18 +83,62 @@ with_test_prefix "memory page boundary" { } with_test_prefix "address zero boundary" { - if {[is_address_zero_readable]} { - set address_zero "0x0" - set byte "\t0x\[0-9a-f\]+" - gdb_test "x/3xb ${address_zero}" \ - "0x\[0-9a-f\]+00.*:${byte}${byte}${byte}" \ - "examine 3 bytes forward from ${address_zero}" - gdb_test "x/-6x" \ - "0x\[0-9a-f\]+fd.*:${byte}${byte}${byte}${byte}${byte}${byte}" \ - "examine 6 bytes backward" - gdb_test "x/-3x ${address_zero}" \ - "0x\[0-9a-f\]+fd.*:${byte}${byte}${byte}" \ - "examine 3 bytes backward from ${address_zero}" + global gdb_prompt + + set address_zero "0x0" + set byte "\t0x\[0-9a-f\]+" + + set test "examine 3 bytes forward from ${address_zero}" + gdb_test_multiple "x/3xb ${address_zero}" "$test" { + -re "0x\[0-9a-f\]*0.*:${byte}${byte}${byte}\[\r\n\]*$gdb_prompt $" { + pass $test + } + -re "0x\[0-9a-f\]*0.*:\tCannot access memory at address 0x\[0-9a-f\]*0\[\r\n\]*$gdb_prompt $" { + # If we failed to read address 0 then this is fine, so + # long as we're not expecting to be able to read from + # address 0. + if {![is_address_zero_readable]} { + # The next test assumes that the last address examined + # would be 0x2. As we just failed to read address 0x0 + # things are going to go wrong unless we now tell GDB + # to examine address 0x2. We assume here that if we + # can't read 0x0 we can't read 0x2 either. + gdb_test "x/3xb 0x2" "Cannot access memory at address 0x\[0-9a-f\]*2" \ + "set last examined address to 0x2" + pass $test + } else { + fail $test + } + } + } + + set test "examine 6 bytes backward" + gdb_test_multiple "x/-6x" "$test" { + -re "0x\[0-9a-f\]+fd.*:${byte}${byte}${byte}${byte}${byte}${byte}.*\[\r\n\]*$gdb_prompt $" { + pass $test + } + -re "0x\[0-9a-f\]+fd.*:\tCannot access memory at address 0x\[0-9a-f\]+fd.*\[\r\n\]*$gdb_prompt $" { + # We may, or may not have managed to read from address 0x0 + # in the previous test, however, being able to read 0x0 is + # no guarantee that we can read from the other end of the + # address space. If we get an error about trying to read + # from the expected address then we count that as a pass, + # GDB did try to read the correct location, and this test + # is (mostly) about does GDB calculate the correct address + # when wrapping around. + pass $test + } + } + + set test "examine 3 bytes backward from ${address_zero}" + gdb_test_multiple "x/-3x ${address_zero}" "$test" { + -re "0x\[0-9a-f\]+fd.*:${byte}${byte}${byte}${byte}${byte}${byte}.*\[\r\n\]*$gdb_prompt $" { + pass $test + } + -re "0x\[0-9a-f\]+fd.*:\tCannot access memory at address 0x\[0-9a-f\]+fd.*\[\r\n\]*$gdb_prompt $" { + # See previous test for why this is a pass. + pass $test + } } }