Message ID | 20180730185045.15565-1-andrew.burgess@embecosm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 66605 invoked by alias); 30 Jul 2018 18:50:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 66594 invoked by uid 89); 30 Jul 2018 18:50:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=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=restart X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Jul 2018 18:50:51 +0000 Received: by mail-wm0-f50.google.com with SMTP id y2-v6so461128wma.1 for <gdb-patches@sourceware.org>; Mon, 30 Jul 2018 11:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=from:to:cc:subject:date:message-id; bh=KFkc7F/qtnoGmGMb6gKWj4eqCfYKXa84CPdyTRWhM2E=; b=UUfGrPrEOqvz4Uv6wEjlEf1FqUvrZhHdqq4YNVJ5Wt51R5gPwpVRBBZYvskFbOHEju vn432keWG4yf0hoofEU+rQkknzSLjykGSvi/2M3LvbPx3aiO8f+tc8aEBxlnLE4gv5pW 9Rd968Bt0G++7IR6eKJxGtpXF1WM/GPwJ+7W6ujTvl6dkp7JxShrDa7P+FSBz+graAoH f+w1jYnjWopUpf3DCcKER0m6+uwjiXj5nn9i6KFN8o+sZSVIlJZPlz8h6bDF9TIfIMTC Srauv8puUbaZES1FGmyJmK3sO72vTY6hxDsuCL1qCA2YQYP7k8yceF+hIQLDqTP2ZCDO J7dg== Return-Path: <andrew.burgess@embecosm.com> Received: from localhost (host109-147-66-79.range109-147.btcentralplus.com. [109.147.66.79]) by smtp.gmail.com with ESMTPSA id k4-v6sm15665787wrv.4.2018.07.30.11.50.48 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 30 Jul 2018 11:50:48 -0700 (PDT) From: Andrew Burgess <andrew.burgess@embecosm.com> To: gdb-patches@sourceware.org Cc: Andrew Burgess <andrew.burgess@embecosm.com> Subject: [PATCH] gdb: Disable address space randomization for a test Date: Mon, 30 Jul 2018 19:50:45 +0100 Message-Id: <20180730185045.15565-1-andrew.burgess@embecosm.com> X-IsSubscribed: yes |
Commit Message
Andrew Burgess
July 30, 2018, 6:50 p.m. UTC
The gdb.opt/inline-break.exp test script relies on capturing a $pc value in one run of GDB, then restarting GDB and placing a breakpoint at the previously captured $pc and checking we get the expected behaviour. With address space randomization on then the captured $pc value is almost never valid in the second run of GDB, and so the test fails. Disabling address space randomization where appropriate fixes this issue. gdb/testsuite/ChangeLog: * gdb.opt/inline-break.exp: Disable address space randomization for the two runs where we care about addresses being consistent. --- gdb/testsuite/ChangeLog | 5 +++++ gdb/testsuite/gdb.opt/inline-break.exp | 12 ++++++++++++ 2 files changed, 17 insertions(+)
Comments
> On Jul 30, 2018, at 2:50 PM, Andrew Burgess <andrew.burgess@embecosm.com> wrote: > > The gdb.opt/inline-break.exp test script relies on capturing a $pc > value in one run of GDB, then restarting GDB and placing a breakpoint > at the previously captured $pc and checking we get the expected > behaviour. > > With address space randomization on then the captured $pc value is > almost never valid in the second run of GDB, and so the test fails. > > Disabling address space randomization where appropriate fixes this > issue. > > ... > > + # At the end of this test we store a $pc value, then restart GDB, > + # and use this $pc value to place a breakpoint. If address space > + # randomization is on, then the chance of this $pc value being > + # correct in a second GDB instance is pretty small. > + gdb_test "set disable-randomization off" Does that turn off address randomization? The keyword implies the opposite (double negative, so "disable... off" means "turn on"). Also, does this work on every target OS? paul
* Paul Koning <paulkoning@comcast.net> [2018-07-30 14:56:32 -0400]: > > > > On Jul 30, 2018, at 2:50 PM, Andrew Burgess <andrew.burgess@embecosm.com> wrote: > > > > The gdb.opt/inline-break.exp test script relies on capturing a $pc > > value in one run of GDB, then restarting GDB and placing a breakpoint > > at the previously captured $pc and checking we get the expected > > behaviour. > > > > With address space randomization on then the captured $pc value is > > almost never valid in the second run of GDB, and so the test fails. > > > > Disabling address space randomization where appropriate fixes this > > issue. > > > > ... > > > > + # At the end of this test we store a $pc value, then restart GDB, > > + # and use this $pc value to place a breakpoint. If address space > > + # randomization is on, then the chance of this $pc value being > > + # correct in a second GDB instance is pretty small. > > + gdb_test "set disable-randomization off" > > Does that turn off address randomization? The keyword implies the > opposite (double negative, so "disable... off" means "turn on"). That's a very good question... now I just have to figure out why my incorrect patch fixed the problem I was seeing.... watch this space... > Also, does this work on every target OS? That's a good question, I don't have an answer for you. Thanks, Andrew
On 2018-07-30 15:01, Andrew Burgess wrote: >> Does that turn off address randomization? The keyword implies the >> opposite (double negative, so "disable... off" means "turn on"). > > That's a very good question... now I just have to figure out why my > incorrect patch fixed the problem I was seeing.... watch this space... GDB usually disables address randomization by default, so I was also wondering why this would be needed. Do you have a scenario where GDB doesn't disable it by default? Simon
* Simon Marchi <simon.marchi@polymtl.ca> [2018-07-30 15:49:01 -0400]: > On 2018-07-30 15:01, Andrew Burgess wrote: > > > Does that turn off address randomization? The keyword implies the > > > opposite (double negative, so "disable... off" means "turn on"). > > > > That's a very good question... now I just have to figure out why my > > incorrect patch fixed the problem I was seeing.... watch this space... > > GDB usually disables address randomization by default, so I was also > wondering why this would be needed. Do you have a scenario where GDB > doesn't disable it by default? Thank you to you both for pointing me in the right direction. It turned out the mistake was user error. I've recently switched to a jenkins/docker combo to try and streamline testing my patches. When running GDB under docker I'm having to supply the '--privileged' flag in order to allow GDB to function correctly. The problem was that I use a separate docker instance to build GDB and then a set of instances to test GDB in different modes (native, gdbserver, etc). When testing GDB I supplied the '--privileged', but not when building GDB. As a result configure decided that my system didn't support the personality API, and so all the code to disable address space randomization was not compiled into GDB. As for why I failed to spot this, again user error, but far less interesting, I forgot I pushed a change to the scripts I used for comparing test results. Anyway, sorry for the noise, and thanks for the help figuring out my mistakes. Thanks, Andrew
On 2018-07-31 08:47, Andrew Burgess wrote: > * Simon Marchi <simon.marchi@polymtl.ca> [2018-07-30 15:49:01 -0400]: > >> On 2018-07-30 15:01, Andrew Burgess wrote: >> > > Does that turn off address randomization? The keyword implies the >> > > opposite (double negative, so "disable... off" means "turn on"). >> > >> > That's a very good question... now I just have to figure out why my >> > incorrect patch fixed the problem I was seeing.... watch this space... >> >> GDB usually disables address randomization by default, so I was also >> wondering why this would be needed. Do you have a scenario where GDB >> doesn't disable it by default? > > Thank you to you both for pointing me in the right direction. > > It turned out the mistake was user error. I've recently switched to a > jenkins/docker combo to try and streamline testing my patches. > > When running GDB under docker I'm having to supply the '--privileged' > flag in order to allow GDB to function correctly. > > The problem was that I use a separate docker instance to build GDB and > then a set of instances to test GDB in different modes (native, > gdbserver, etc). When testing GDB I supplied the '--privileged', but > not when building GDB. As a result configure decided that my system > didn't support the personality API, and so all the code to disable > address space randomization was not compiled into GDB. > > As for why I failed to spot this, again user error, but far less > interesting, I forgot I pushed a change to the scripts I used for > comparing test results. > > Anyway, sorry for the noise, and thanks for the help figuring out my > mistakes. > > Thanks, > Andrew Well, that's good information to know, thanks! Simon
Paul> Also, does this work on every target OS? It doesn't. The target has to implement the supports_disable_randomization method, and then actually implement the disabling. At least macOS doesn't do this (see https://sourceware.org/bugzilla/show_bug.cgi?id=23365), and probably others as well. Tom
diff --git a/gdb/testsuite/gdb.opt/inline-break.exp b/gdb/testsuite/gdb.opt/inline-break.exp index aed38ed631f..00a5467d617 100644 --- a/gdb/testsuite/gdb.opt/inline-break.exp +++ b/gdb/testsuite/gdb.opt/inline-break.exp @@ -264,6 +264,12 @@ set line [gdb_get_line_number "break here"] with_test_prefix "line number" { clean_restart $binfile + # At the end of this test we store a $pc value, then restart GDB, + # and use this $pc value to place a breakpoint. If address space + # randomization is on, then the chance of this $pc value being + # correct in a second GDB instance is pretty small. + gdb_test "set disable-randomization off" + if {![runto main]} { untested "could not run to main" continue @@ -289,6 +295,12 @@ with_test_prefix "address" { clean_restart $binfile + # We're about to reuse the $pc value from a prevous run of GDB. + # Ensure address space randomization is off so that the inferior + # is placed at the same address as previous, and the stored $pc + # will still be valid. + gdb_test "set disable-randomization off" + if {![runto main]} { untested "could not run to main" continue