From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64756 invoked by alias); 28 Jul 2016 06:28:23 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 64741 invoked by uid 89); 28 Jul 2016 06:28:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=assisted, D*mentor.com, HX-HELO:sk:EUR01-H, H*r:15.1.557 X-HELO: EUR01-HE1-obe.outbound.protection.outlook.com Received: from mail-he1eur01on0040.outbound.protection.outlook.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (104.47.0.40) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA256 encrypted) ESMTPS; Thu, 28 Jul 2016 06:28:12 +0000 Received: from VI1PR0401MB2671.eurprd04.prod.outlook.com (10.168.66.19) by VI1PR0401MB2669.eurprd04.prod.outlook.com (10.168.66.17) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Thu, 28 Jul 2016 06:28:06 +0000 Received: from VI1PR0401MB2671.eurprd04.prod.outlook.com ([10.168.66.19]) by VI1PR0401MB2671.eurprd04.prod.outlook.com ([10.168.66.19]) with mapi id 15.01.0557.009; Thu, 28 Jul 2016 06:28:06 +0000 From: Alexandru-Adrian Oltean To: "Breazeal, Don" , "gdb@sourceware.org" Subject: RE: hbreak reads memory Date: Thu, 28 Jul 2016 06:28:00 -0000 Message-ID: References: In-Reply-To: authentication-results: spf=none (sender IP is ) smtp.mailfrom=adrian.oltean@nxp.com; x-ms-office365-filtering-correlation-id: 7b17a589-3d07-4237-2ddd-08d3b6b0564e x-microsoft-exchange-diagnostics: 1;VI1PR0401MB2669;6:/EgweelWwBnOb5OAR8iyEnLTWwvYWLLrP2JDfHXmsT+Xx/EbfUtoeuF1trRtK0qFfI6oP9kC1J5aR7Hf2DErk2TfDbszDaDleeSM3iGGMGCKh11yeRCo3g+/3hiH0C6h8KicsImhl7DmVvaNXa5tN302xZN5My4jAdcfQVYiO27vY64+kI20lqbtslp9TViwvSj0oW81SzBwPtrSItC5IMlDp34VATeuxCErFcYW1OvbZSVJUR4wshI9a0EHooz6EvBMG2U6KWnClHpc3pZvEkEIy5OMugcfAAn6S5oo6nllLN4mJCkUIz4/7rjnINrhZq7FIgK/1Ihb3NaKDzXFGQ==;5:wMaMpcfIWXdckXFcBBRZ8xHqob0zjxBegtzNmr0PGGRCcpBf4C6VeXBmIGWQ7KQ568D6DzORD4WDCz8CjyHsvoZBVEobfBKvrhtydQYaB5S0XaNmdw2M3VSkY79T1qiZkJd5pzpHXcZbRw5IXodfSA==;24:I0k0jIL97iCKB1Cw35ohpB4vEFS8QOb5cNGRoZ+zO8ldXEJrsqCGJmMcKVqbetZxBZ8sCRYNL87GLQqRPonWvpnkbc1H3Eehp/fqTl32S34=;7:H6a2EQwpokaK6EGpEtAGkIKByQZDwkyxg/IgrI1cBizYpW9NK2yoBkdzxSaNpUOC+PYwG37X29G9k7MGXAlt/g6A79YRP3m3OxMQZ4snFuZcrKJgpDN9OcVZ3RIMpPDcfByYZOJE5hWRVeuJ+O5a/ExnGNePisuRrjj3VqNlcLvve0q1qV4eR8HaSQbedHwFXEcMtahVY38wXUzhlFlh8qD7m1KTEVc0fJpdh6b/lcO3hBklqY58yyGKBRMn40Cl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2669; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(185117386973197); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026);SRVR:VI1PR0401MB2669;BCL:0;PCL:0;RULEID:;SRVR:VI1PR0401MB2669; x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(7916002)(53754006)(13464003)(377454003)(199003)(189002)(105586002)(2900100001)(122556002)(2950100001)(189998001)(10400500002)(77096005)(66066001)(5002640100001)(19580405001)(106356001)(76176999)(19580395003)(107886002)(92566002)(11100500001)(54356999)(50986999)(586003)(97736004)(5001770100001)(101416001)(3846002)(2501003)(6116002)(102836003)(3480700004)(86362001)(3660700001)(33656002)(3280700002)(9686002)(68736007)(2906002)(76576001)(7846002)(305945005)(74316002)(87936001)(81156014)(5003600100003)(7736002)(81166006)(7696003)(8676002)(8936002);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0401MB2669;H:VI1PR0401MB2671.eurprd04.prod.outlook.com;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; received-spf: None (protection.outlook.com: nxp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nxp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2016 06:28:06.5883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0401MB2669 X-SW-Source: 2016-07/txt/msg00037.txt.bz2 Hi Don, I forgot to mention one important thing in my previous email - I'm setting = breaks using addresses not symbols.=20 So even with this approach I'm still seeing that memory is being accessed. = I'm expecting a hbreak on a given=20 address to skip that function prologue analysis.=20 Here's what I see when activating debug in gdb: hbreak *0xfff54d64 Sending packet: $mfff54d64,4#36...Ack Packet received: E01 Hardware assisted breakpoint 3 at 0xfff54d64 Regarding your suggestions, I know for sure that setting memory areas read-= only or inaccessible helps. The other suggestion involving 'set trust-readonly-sections' seems to allow gdb to ac= cess memory. However, I'd avoid=20 managing memory zones this way since HW breaks should really not touch memo= ry at all. Thanks, Adrian -----Original Message----- From: Breazeal, Don [mailto:Don_Breazeal@mentor.com]=20 Sent: Thursday, July 28, 2016 12:42 AM To: Alexandru-Adrian Oltean ; gdb@sourceware.org Subject: RE: hbreak reads memory Adrian, I think this is due to some function prologue analysis. You might try sett= ing the breakpoint on an address, e.g. instead of 'hbreak foo' use 'hbreak = *foo'. The breakpoint should then be on the address of the entry point to = the function and the memory accesses may be reduced or eliminated. You might also try 'set trust-readonly-sections' and/or set mem inaccessibl= e-by-default. Those may or may not help. --Don > -----Original Message----- > From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On=20 > Behalf Of Alexandru-Adrian Oltean > Sent: Tuesday, July 26, 2016 11:29 PM > To: gdb@sourceware.org > Subject: hbreak reads memory >=20 > Hi everyone, >=20 > I noticed that setting a hardware break using hbreak will trigger a=20 > memory access at the address where the breakpoint is supposed to be=20 > installed. Can someone explain why is that memory access needed? I'm=20 > thinking that we might be in a situation where that memory area is not=20 > yet initialized/accessible (maybe MMU not configured yet) and the=20 > access corrupts the debugged target. >=20 > Thanks, > Adrian