From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18163 invoked by alias); 1 Dec 2016 18:10:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18150 invoked by uid 89); 1 Dec 2016 18:10:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=initiated, (unknown) X-HELO: sesbmg23.ericsson.net Received: from sesbmg23.ericsson.net (HELO sesbmg23.ericsson.net) (193.180.251.37) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Dec 2016 18:10:19 +0000 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 64.9C.32482.68760485; Thu, 1 Dec 2016 19:10:15 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 1 Dec 2016 19:10:13 +0100 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=antoine.tremblay@ericsson.com; Received: from elxa4wqvvz1 (192.75.88.130) by HE1PR0701MB1883.eurprd07.prod.outlook.com (10.167.247.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.771.4; Thu, 1 Dec 2016 18:10:09 +0000 References: <20161128122758.7762-1-antoine.tremblay@ericsson.com> <20161201144401.GA19289@E107787-LIN> User-agent: mu4e 0.9.17; emacs 24.5.50.1 From: Antoine Tremblay To: Yao Qi CC: Antoine Tremblay , Subject: Re: [PATCH 1/3] Fix inferior memory reading in GDBServer for arm/aarch32. Message-ID: In-Reply-To: Date: Thu, 01 Dec 2016 18:10:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: DM5PR02CA0050.namprd02.prod.outlook.com (10.168.192.12) To HE1PR0701MB1883.eurprd07.prod.outlook.com (10.167.247.23) X-MS-Office365-Filtering-Correlation-Id: fce54b44-f787-4abf-ff53-08d41a1549d8 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:HE1PR0701MB1883; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0701MB1883;3:agauWukjFslubtixleJ+VwMuJihRDjOVH/trsUzsymmXldb8cRn37U+J3NEWLugKXVHSdov9DugqH1EC5xj2MCHQ2PBCHcgppWJ4QIm1FyUbP+u9/plBtYIAoNQp8QhVEyLn2meFf8nhSUk8RifiEvPQN9guDmmiMIfO8bmUxpB2eGojB+S6S2xq+PHAY36OtXZDFSy6bCL7JOxTnWXcECF6qlvcxooidNNVRGaWi4cugNRcxRKs4GpARhNYVUsb6EL5U2DM8daXBTVh/UWmXA==;25:i2uw9Oi9WyhZVBfh8inPZG/hZj+EDBDakvxnGUN9wDzz04zq5g5tDO9tpS2BFMMaxwwS3qmbk//Hj3BpXyMf96iqcc11B7iWjIzAKWu89p7/Tlk4p4HwD3hcED51sbM+l/bIdLpyM2HTsX3+8i/UcGwgn8lBfGj5YiOrfWA8n3A9mdGkcriuSg+lOemsEzmjrSmUdwfDaJ0idLk/NgYRsEJQD5EBHEm7uSjuYQO3DYYTEiXjQu4vBLdFw2rZD8woJ85F69+jr6zuFb3uRNvOf8iCuvXiy8FoFSr/ybG/Mkp3UFuXHLSlj9IwB2qr4FjGx+3u5GX3MnVbUTzpySTEoxS2qxZu8Jg70mmwl6sdirU1OG3gtJnXad0GhUQNUO1LxoYIfeepAxDLsrqya2NmlVbw1ixll7JO9Pe/g9yaCkWQoK9xTzRSzzE5P+M2ndJ2UOjn6dqd8SC2GYKvhB/obg== X-Microsoft-Exchange-Diagnostics: 1;HE1PR0701MB1883;31:dXBPK7O7KGhzQQ1758UDJWuahYbUnKoRsALJsb5Qcn6VZbeQxOYs/M7gNaloNNTb2JGAKoIiaieHhlV9Rp7dCnCcL/Bwaex2JSsRhSJQ+bN/ur+6hiH6nncAdC2xLSWJxEKtAhh+8PENewP5IKyWyO0F7Z/u1n18/7InSoWFA9CfLbJkUOdvveMGgjxnMAF7z2Se9MvTxqq+6Mt9SuvbeZdgNUwHskZtvfh1TqbTYjOdxcZqVq8P+04cOxcNBYxRVYme436RqpO3KNgCllQHOS1tFoo1dd+A7EtfrQXXBlc=;20:rYn1OA61B6EgLfRAhb7MnZS6ud3q5u4HA//prcR0dJTINSv7lOP2MfP16QTvsRj6/A9jki7wMz63aPhJOmyuhaJqLFGtjkqyAghDMd1t2Xab/ZrITcQ01QcKa15GEyjHjrXhU8uTZfyrxhXngdwCBO6cXhtir1TH5AF7TBNdRELg8fduja3WDpddBXURSkra5RRbPBCrDEGq7zpYu2HDIOpGs3l0/fNxNn/uHHXfprK81FqKyxgFlUiw+dRWgo/YIpxt+yQyuwGDTBMHdIhjluBOOQ0ti9tFz3ByWABaFhIncfu5/9SihAss94GDvA1UyTwiTNz5QFbRNj/kqiyG0RXTXTYRfLuoXWy79gV8H+Lt5U9DUWyjMc4VAQAPcfCzquR2VTJF2cC3g2Co/ghYys2IJKAaJYfL5nmLEdnfRKm7FXoSi/399dB5wnhjPwpK6dtYPXRHyIahmOhGolGYfboXpo6K7G6EtPAn8xvgFl7Nz1CFSlyrqF8E6C2M0/hF X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6042181)(6072148);SRVR:HE1PR0701MB1883;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0701MB1883; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0701MB1883;4:ckvR/8ku8meu/lsA4uH8HNvZ8DTVQQihUy/pQgj+34Buck0g9prm4S6Zce9nmuJuWbOidMeKHa41NT1U2lnf5vhD3n9vM3ZROzjssettIWZuD0J0qzFqkXH6lpLlkIryr3USzN/OFDtEgMBa2ge/NN4C5HL6I/Z24TcfshtY6mGCKwzucmmU/WtSxwhgeyDouwyzzzQJxZBJnTx9PoWD5CHExjJJjEew4zinwEiipHJiTmtccMTr6PhH3HfKqPcvB2iwhwEK8ka0KRSInIEKnQXOeh1p+I9/ij1W4o2N1uP3BHetPx4NPC/NOlez7Ce4EvlU3z/hD4jYxb/11HdfOao0Mukect3DutY1TYSe3703H4gUiBkJZoYS7KIg/yXYjOvaLaVxh00cBlmjWscXH5Wj3I4/MeseuB6c0+yEdYn/jtwaVoB3vyOG+wPXe45eQkwxsCwqmTeIx+UHxjZoZcugyKgxLgNtH7yZxgonUxtgOjHIhNSuIp99wxbL5jrqF6ye0XYZqjuzEUeyyfK5caJTzmJ8tcMKiOOU/3wHc/bbSVbNuX1PbJlFwaggiF8sYqzjGxryGfFCqtCSFYZzyg== X-Forefront-PRVS: 014304E855 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(7916002)(199003)(24454002)(189002)(33646002)(47776003)(68736007)(4001350100001)(39060400001)(97736004)(7846002)(54356999)(76176999)(48376002)(66066001)(50986999)(229853002)(4326007)(6666003)(2906002)(7736002)(5660300001)(38730400001)(6496003)(733004)(101416001)(2950100002)(6916009)(6486002)(1411001)(305945005)(110136003)(105586002)(86362001)(5003940100001)(42186005)(189998001)(36756003)(81156014)(50466002)(81166006)(8676002)(6116002)(93886004)(92566002)(3846002)(83506001)(106356001);DIR:OUT;SFP:1101;SCL:1;SRVR:HE1PR0701MB1883;H:elxa4wqvvz1;FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;HE1PR0701MB1883;23:pp156+SCoueQwuPdVnE2awUsQJQz7mu6k5BkO/8?= =?us-ascii?Q?4dhZubWt+jdGEOCbkAUCD9YVMAX5CUuDGFuW2Va4Z87GUabRsXYqMt7cmnVf?= =?us-ascii?Q?FUdiIl8CDYob0OFBgUcAAyLNbhSA95OzWp6Oanyx6P4QMHk/Lm2z/biVhUrP?= =?us-ascii?Q?7kFP3KJBUnEUoqW1huYd7XwGfNR8ZoPElxxRpUxyyRDeNmIJEKDAJysF0dwc?= =?us-ascii?Q?1IpMKZbLETVlQc9x4v5f1RosQ5kLBJlBZbe9FbYiOf/I8IRlCnT1UkfbevH9?= =?us-ascii?Q?gJlk5tkDHC4UpzM6i0+f6OWL7mz+61Dy1ZyqsVtWAA/LxR181J2V8f/bbIJz?= =?us-ascii?Q?XOta/YMRdSk8WflNkBZs1J47L9HjtDoi9FDjfvFiXKfzA8Ud4PXOZLpFcpbx?= =?us-ascii?Q?Ug2XBQhYynnVoi7USR6HGEZTGTqYuLMioj7EDheCHH7mi+AqrmrCArfMQ4Dv?= =?us-ascii?Q?71tj9VvRJn0aS3kFDe5ZfNUmOV4knYkYEp/RmcS130pW0wa8b034B9gTQ/SR?= =?us-ascii?Q?l6dfYuBrGd+SI2rBDlLZOgiUC6SME41nZxIZQkX+PayInU9GQM0I35i7rV4g?= =?us-ascii?Q?+wgUMbdL/xibms0ZtzzT+7wdEcCqsNFtRaed/tlz9sZGScE6h7wQweW6lSDZ?= =?us-ascii?Q?lkdhzJGD7BaZIpqTJfnT2SJAnp1TEscg1l4K/0HtKSqhuYb1JHBaYfcL6Wkd?= =?us-ascii?Q?17GgZJhx8x/YHmq2E2i7OsSVuwroIfj99jjatTv00WJ2UvBg27IbkHdGgNVD?= =?us-ascii?Q?06THcuDtd+Szt2Lx3oKWlhLAeQO9iyUc+InZnUzzWkWnvKfj9JPmDrqjliaW?= =?us-ascii?Q?w5227qU6Nna+UqrlMgZr9Wy1V2oYIXmEZLSOLtMvQZM9jgN3YtcZUCoeaBeg?= =?us-ascii?Q?f3VK4vtyJwoKSlS5sxkPskwNyppqOpSyUlU2CPbymRI3MlQ+KwcCROz9UzQi?= =?us-ascii?Q?Z4xISNuCq/8fHEUqRxz+ZIdV3y1Y7Ts5UHghdveRl8/OZwOZFwzTfgUvrELa?= =?us-ascii?Q?eYRWHZ+UrbmGoZQXW+6a9yc1H2LnH0+ZMr60L5FdsTgdTcCUwZ55PcKm9p7P?= =?us-ascii?Q?P1kM5gDH0cOHcKtqXovs3fDQQUkw+uPUyHIorfctoRREK0DVlpmb0Zix4+l2?= =?us-ascii?Q?47LQr3G7Fcfd5jUawuk4ypozrIgItWO4n4eGiYSolSpMDyK8m0LpAq08iAd8?= =?us-ascii?Q?4EOGIwmcqBmyn98/9/OhqXh7oMMNUnPS2trpx?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0701MB1883;6:eUzOq0hjFry/1/TdqigtcPBqtXttVETdL2fG4NaZGcmgkUjBueuIIrgrAyk1CCJ/1FIrjeLyEXXZbyXn7OqXdFPX5/zIsvauKDBVdxuc8c4Tr0/rangtZC4ScX7SLT/gadfh5fQWJ+056V2CYqBc3u/Nw7600QiXX9z2o1uz10hxV/i5wzgVemq/ashaFTZ9YzOK9lN7Fkdx3bkLZ0vGEw0FDG2g+wCVvH5lgjUoqs8G1LwaMJ6gl0XhSCRd6B5GapPYI/+Lm9nRJv3BBQQpWEF4GLAL/xF78px1lQaenQCGOFCQX3OGlVeEjV0PmgPUpVaN4P8+FWBFDfdvIvZQ7nJ/cZaKVOHpDSq/rCP6UEKt8JrCHHaMm5geA5tnNoPbBdtvb7WrunMffpY2w+aVBGFBhYXXGeAMN3Hji2AHq4oywEGe4Agw5FT9CkwiEF/RJbvP5GRGSJm/o4Qjvf32ow==;5:Fji8CwkBkR/0hKNCLsWug59jxmzKZPi0IfGJWcVt24uvDc3HTmBJoibLcdDpZ7hCGbQtKZXpjJPXZMvvFYbugh95rP/0AEKL+qQh/77h1Wo83EA5bQwUuiNGJHo7tqacZF9B8AYKeaEAtaWK3WPoRw==;24:kYnNtcwG7XaYYQc4Mn3jIVQaNd1U/4p4iNslZbH+TFljE1V77NS7FM30IZ3gluRlo9/0ga83RFHfqIJiBtxGaZczKjVqtC8WTHME6R5bX1w= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;HE1PR0701MB1883;7:hE9Fc76STi/YT5v0ncLy4j6y8B7Wk2hXSlsUPu6g8xfrIiQFev2Wibtfugk/V3Jxf4OFdfAx1traFT3s1FIyXngyMEe/rc5GqWa0NVTzMAXa5/FXrBQpmipyKZjVfYLWv3JSVBu4F/gyMxpOfNqysu66qGBrxwGn7C3nmJB34Ao2D5m0K9qlmNgiWMTAr56r8/rOSfxARzmOERzb8zujha9Y0lSd9nb/xl0srU/2PQcIwg0PwdS744wByffGbmW+5VH2SMJEghSwA7yyOK1/xv6FlTiwCd2fAvNgkobUzp8f0zLqNAyyoDQ5AwDqu3vTNMPsj7FjXsL77l84z39qZwfOZ+7eMD5GTSqPXlsDfEbj31pB5SLc7CCMe9iNF2EPGASxOcHGqwNola8CY7g0KkM+JtJqI5D0sNSUUpW7CZWkAiS9VVATgqFibDjxIcxaXGNcijorOYdv4rQDARt6+g== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2016 18:10:09.1337 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB1883 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00050.txt.bz2 Antoine Tremblay writes: > Antoine Tremblay writes: > >> Antoine Tremblay writes: >> >>> Yao Qi writes: >>> >>>> On Mon, Nov 28, 2016 at 07:27:56AM -0500, Antoine Tremblay wrote: >>>>> Before this patch, some functions would read the inferior memory with >>>>> (*the_target)->read_memory, which returns the raw memory, rather than the >>>>> shadowed memory. >>>>> >>>>> This is wrong since these functions do not expect to read a breakpoint >>>>> instruction and can lead to invalid behavior. >>>>> >>>>> Use of raw memory in get_next_pcs_read_memory_unsigned_integer for example >>>>> could lead to get_next_pc returning an invalid pc. >>>> >>>> Can you elaborate under what circumstance breakpoints are still in memory >>>> when these functions are called? Can we have a test case? >>>> >>> >>> Here is an example: >>> >>> In non-stop mode multiple threads are stepping, like in the >>> non-stop-fair-events.exp test. >>> >>> GDB: >>> thread 1 >>> step& >>> >>> GDBServer: >>> thread 1 is at instruction A >>> installs single step breakpoint on instruction B >>> >>> GDB: >>> thread 2 >>> step& >>> >>> GDBServer: >>> >>> thread 2 is at instruction B >>> >>> GDBServer needs to install a single step breakpoint at the next >>> instruction from B. >>> >>> To do so get_next_pc is called, but since the single step >>> breakpoint for thread 1 at instruction B is there. get_next_pc >>> reads the current instruction as a breakpoint instruction and fails. >>> >>> Note that I used a user driven example here to make it more clear but >>> this is also true while range-stepping in a loop for example: >>> >>> - thread 1 hits its single-step breakpoint deletes it >>> - it's not out of a range-step so >>> - tries to install a single-step breakpoint at the next >>> instruction >>> - but thread 2 has a breakpoint at thread 1's current >>> instruction and get_next_pc fails. >>> >>> This is already tested by non-stop-fair-events.exp, the test will fail >>> without this patch. >>> >>> Note that this test is testing both range-stepping and the user >>> stepping. >>> >> >> Sorry I got confused with the code patched with the latest 2 patches I >> sent refactoring the single stepping code. >> >> Considering the current code this is handled by the step-over process, >> and should not be an issue as it will always step-over before installing >> any single-step breakpoints. >> >> And step-over removes all breakpoints when stepping over thus >> get_next_pc is ok. >> >> This becomes an issue like I said before with >> https://sourceware.org/ml/gdb-patches/2016-11/msg00939.html >> >> Since with this it's possible to install single-step breakpoints without >> a step-over check. >> >> We could consider this patch a preparation for >> https://sourceware.org/ml/gdb-patches/2016-11/msg00939.html >> >> or just a good pratice to use target_read_memory. >> >> Thanks, >> Antoine > > Just to supplement about: > https://sourceware.org/ml/gdb-patches/2016-11/msg00939.html > > If we consider this patch the is 2 reasons we can't install step over > breakpoints. > > One is to be able to delay a step-over. > > The other is since GDBServer inserts single-step breakpoints when it > processes the resume requests and threads are about to be resumed. If > threads still have pending status, single-step breakpoints are not > installed, so it needs to install them in proceed_all_lwp. And in this > case the single-step breakpoints are inserted outside of a step-over > process. After some more thought, it can happen even with current code too that single step breakpoints are installed without a step-over. Consider this situation: In non-stop: the user issues: thread 1 step& thread 2 step& thread 3 step& In a similar way as non-stop-fair-events.exp (threads are looping). GDBServer: linux_resume is called GDBServer has pending events, threads are not resumed and single-step breakpoint for thread 1 not installed. linux_wait_1 is called with a pending event on thread 2 at pc A GDBServer handles the event and calls proceed_all_lwps This calls proceed_one_lwp and installs single-step breakpoints on all the threads that need one. Now since thread 1 needs to install a single-step breakpoint and is at pc B (different than thread 2), a step-over is not initiated and get_next_pc is called to figure out the next instruction from pc B. However it may just be that thread 3 as a single step breakpoint at pc B. And thus get_next_pc fails. This situation is tested with non-stop-fair-events.exp. Sorry for the confusion, you can consider only the two last replies as valid.