Message ID | 1503828934-26404-4-git-send-email-simon.marchi@ericsson.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 82322 invoked by alias); 27 Aug 2017 10:16:39 -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 81602 invoked by uid 89); 27 Aug 2017 10:16:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: sessmg22.ericsson.net Received: from sessmg22.ericsson.net (HELO sessmg22.ericsson.net) (193.180.251.58) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 27 Aug 2017 10:16:00 +0000 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.EC.20899.2DB92A95; Sun, 27 Aug 2017 12:15:46 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sun, 27 Aug 2017 12:15:45 +0200 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=simon.marchi@ericsson.com; Received: from elxacz23q12.localdomain (80.216.43.226) by AMSPR07MB312.eurprd07.prod.outlook.com (2a01:111:e400:802f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Sun, 27 Aug 2017 10:15:44 +0000 From: Simon Marchi <simon.marchi@ericsson.com> To: <gdb-patches@sourceware.org> CC: Simon Marchi <simon.marchi@ericsson.com> Subject: [PATCH 3/4] Add thread after updating gdbarch when exec'ing Date: Sun, 27 Aug 2017 12:15:33 +0200 Message-ID: <1503828934-26404-4-git-send-email-simon.marchi@ericsson.com> In-Reply-To: <1503828934-26404-1-git-send-email-simon.marchi@ericsson.com> References: <ca635448df367f79b0b833d751169c59@polymtl.ca> <1503828934-26404-1-git-send-email-simon.marchi@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain X-ClientProxiedBy: DB6PR07CA0078.eurprd07.prod.outlook.com (2603:10a6:6:2b::16) To AMSPR07MB312.eurprd07.prod.outlook.com (2a01:111:e400:802f::24) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0325b3cf-b778-4a55-8d40-08d4ed34946b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AMSPR07MB312; X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB312; 3:S6MoPsiCiHBYWtZweEDw6tjGW+GBrhJb5qs1y53z7iQcapGj3jk1lcUpgg/ixh4aJBmTcC5XIkx68cS91OGb/lnTS5T6F/rsMVXG66y8Z9+nUiWQuzHk5hJXrYe5xVUnPq1Sudm65fiZxQPnpTL+WphkM1Tnz/Raa7/ICDSEcFZoiyMhWiDGplb0wfKuaKCRjwDHhmWkg4ffqyGT2ZsKhvsgXOvQ4KcJOzXPNSQzOleM0ZwzHpqIMJViwZiH06O7; 25:FcGTX0izYyAf/9wLWUuNkX3LAkYrFoq7reHUSfI2V4JJ+czCPcXJ11jCNUj6s+QvfnhQCQLNM/r/5HNnd55nBv1PNdIW1nS+60zCZJdhOjLs7sfhjr9+hDb24k0H4nFQvQ8LDO4YAHMYjpa/HxobP7FTb1c/7UrMcE8zbzs/j8KEjsos38VK3CVEnhxWUgqWHlKhp2mQPG57on7+HZbvNua4PZ3UjMF6VrEYmZFYGwzwJSJQkYaqo4e8nDRD54d3W28XiQLQysJlzfKOiBmG57g1ZVOh6oJnv65BhtbOrOYA5ZSaeUPUiVJfdCCTFVxsssSStsesniTmctI/Ov6dSg==; 31:q6tRw5GgOz7B1hTNJfmz7g/zzoKVSetfFWdz4cORCM76lM49HBNEO1q13DmTaL7Jk8RabguIPZRncMOV4XJhMUqFXSrp6UiWD2TaQCIeH+xPBXZqgsmnHws5yXOgi8HjOKIv9MthdDiJo0n/qzUachuK4FRYr54B6AjnhucFVafkJnUMPcisLrRzR1ryfQsYKd797BE0c1Z5Ku2TlqOmoJbF8ja0AYCs1rbs0fKdRos= X-MS-TrafficTypeDiagnostic: AMSPR07MB312: X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB312; 20:YQe0ZOnCPd5NIhEC8mXGEWb86ZoThXTlw/QJM2P7iQ/2fonDEOqzBY9QM706ZOLwhj4Zl2bvn6bKO9h8+nbf6y0xsRcvdCBm8Ka4FIp/wMkJ8Z7qYqB9jUrpR/5VnUlJeF2IVn/5D8NqMPUQxZs8QTxHnlPRqU68O4YBCZwzBhZZKHxcbAPwl4ixUHJOmltEGx0mBZc4xlOxmMIknE9Gcgxo9zL5jKePlZMMVvdZDfCwLNqUZL8MQmOHybP1S8q94BOl6QGq4pTWlrKJqkFOCcZiL6vN/jV7T1DDoTiYOKyL6zen5bF4MRizyssoPiSxJ2UCfW9Ve8H+ePzAjmQAIgq3JQ9rpHXW/MqoBeYABBeeAyjJ/1uFBUe8kKWp2nWEpkYNfnd8CuFBfrZFLSyy4Mdxv7dzhybQ6J/LfLfjBS3ZU09dLXjsnO7vYURYN1RxMVyu2i2ilPN+UMR3MEbBF0vuqH3QbsuJUxaswQaOlLe/+W+lN4bGVMhgGVdejill; 4:Jn3joDYzqBW8mof77G/F49lywb2oU6PnWK32D18so4wkP2hm8T+CPhAoDfNYvFdw94O/JTEmaa8q/8rf55FpvsxsopugG/QiN44Opj3vfOG1dE5o0gBSATgAZ0CvSALO58n30lM63yEN66P0CiEy2DrlY0j+LpRm8B1v+CD4ri6FNL0Eq8sUrACtx6d1P4774PfZxZUUI0qhGHP82Vbw73B2iPZ+1HVFtdrQdkqU7UuyW6Dtv1ACy/CNUT06VhPW X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: <AMSPR07MB312C3F806461047A20309EFED990@AMSPR07MB312.eurprd07.prod.outlook.com> X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AMSPR07MB312; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AMSPR07MB312; X-Forefront-PRVS: 0412A98A59 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(4630300001)(7370300001)(6009001)(54534003)(199003)(189002)(478600001)(105586002)(50466002)(106356001)(6116002)(3846002)(2361001)(42186005)(48376002)(4326008)(2351001)(33646002)(5003940100001)(8676002)(189998001)(81166006)(2950100002)(81156014)(6916009)(6512007)(5660300001)(97736004)(107886003)(101416001)(47776003)(66066001)(110136004)(68736007)(53936002)(50986999)(76176999)(7350300001)(50226002)(2906002)(6666003)(7736002)(86362001)(305945005)(25786009)(36756003)(6506006)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB312; H:elxacz23q12.localdomain; 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; AMSPR07MB312; 23:Uc65cg7qFCXlNel0wpIOgL7V7rOB7SortdSabr3VXk?= =?us-ascii?Q?YUrjh+xt/VPzFfAjr/T6ahsIZU0SdvtMfpi06SyDAsU9y57yyLzeBAFL6WLl?= =?us-ascii?Q?6wO//PTjCTPu/kEfOOMCDNZK0Au0fQklgI3iRviMnTZoqAGrv4YWBVILIa7F?= =?us-ascii?Q?iADrjx0JGQgHR3Szj/bVcY1f1lrurP90Sx/lunsTflXd8FCx3hJdqWNOBJAc?= =?us-ascii?Q?j8IM1BkMa6ww61oBdQ0mfgg2fsR9D9MZjc52B6GIx03UkzQ0WDEe2cijBASD?= =?us-ascii?Q?txJl9eNTdFqw5/ymyJi2Zlc4oXtT5UVSPuIt98RijjhwiGcmeSsHJfYjfHQ8?= =?us-ascii?Q?+Jz+ixStSPhPza7KgcnAxbgin8xkR+4lQUU6ULatLKABCqbRsvOp8DwUWOmV?= =?us-ascii?Q?Ht32mJ/egy1bQ7rPMRcCvOez8zA2wKvD+o1v3JHSe1hjNI3vKL4Foe0Ze5Y7?= =?us-ascii?Q?JbBRYQxsAoi7FN8/PPSODy8VFtEAREx0TTcySLWq8fm5vgrSUYlT5u8gai9m?= =?us-ascii?Q?Y5dKHEd0E+R0p2q0bjiRjXGli+UApxyjtdPXjnzbSyqWuibAIutBrCjICv93?= =?us-ascii?Q?jJUl8cjJPBeyr7OERYzkfXWbLG6EWKAGnFl+jbSEsLI0OzwACHFhIVddkDhP?= =?us-ascii?Q?fgmp5yFC//2Oo/WWvg1WWFCDBy54BnilzZ8vIeqK5FJT5RiUKEqW5TRSpVt+?= =?us-ascii?Q?KN9Bpspud2x0NuZ7K3BVkYrRQwZCVx+Jmu4G/fXhfLU1kOLyNSpIGzPupW5v?= =?us-ascii?Q?e5pZG84lXsBZEM5f9tbBDczg5ZX5z1HRT8z0f7MIfUibNPam2D+nJU9uTRru?= =?us-ascii?Q?cwkj74P7oBMk0bYZ97sBxObAqYfXBI83oAD2SBYxBboWdvcLHzaARCpSVzvn?= =?us-ascii?Q?NCLYal0GbYrL7muymeAZGodeCWg6aPjJkK1ggZHQcbXIP32Pb3rpvmlBq2Du?= =?us-ascii?Q?IjrOWCjSndmMJggGWuBZ/71DEkWRLprjl6s6DRmYCjJjomPoTwV4nwa0vb4c?= =?us-ascii?Q?IRHHnIxaM9oLFI1pCOB4N75tiQzrAzKvhGTGHKc0ivR+651FnrrS/FLXb8Y8?= =?us-ascii?Q?fgIoVlSKoWWcOAyZECKbBzuLSY2MZ6cI7EwFU9KU9qRhWJabG+pGbLRzS9ou?= =?us-ascii?Q?dDKEKGow343PxLarqHjkXkMhcgA5BfUutnKPG9/OktGETSd/Bx2Q=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; AMSPR07MB312; 6:qJ5ugqY4Gt4R5S9c21AqkT+3XKljfrC2coC8AwVzikugM1JSZp7ejxOjCS1JrF9oj7EhtKxvVX2S9zBpWlPx/bxuEprMVKusONho2th+nJ5HE03o37RlmWTf3w6ZKSJ/NrV5Vo7rjpp1d3GJgit1SvLq1C2R3k5nY/KL6Lvaw60U0i4WJYmJe/y05ue99yMb3IG92XjEJq2UDTItWB5P0qoBlfPRg5IODquxPtKXpSzzRdfB6WyF/jxgaPfatNYC58yGD94tcBXNMVwuO9M+aZW6wL+BQ26uIKyM1f0oTsu5h/z2pDtuBHtKMSbiQWCjmhnD4GWfPrxrf3l73jfJGw==; 5:2r/TkWrzGo7tAQ6kC/mZb1/KOh1p2o44gKmO410NEhimBRwvUnrtBl2acHDYWOIWgaB81VZXkcqpCn1H7GrUmx/CWxh/p3eLfSvoL3/PPEc4n6N8itOZTYu7L3fVWXlrtaWX4Upfc+6lev6fOUSFhQ==; 24:fscu7pkVhLXSTjVk2hwm/JmQA3BZeOTsBh61Id+ui3bonGGACFM8bDvS/lLlKM20m+/sYD7nkjulhhlhXQXoRakdwskCKNzm8OAycTw2wv4=; 7:x3vwNNPfyHNkzLERixnwO6K47hpk+vQFPSbapVz78yc9mWQT/CsyFgXukEQH+mdo0Phe8GwKhD1h0HqM2ujf/3w7cAkPNuOQm4D5ILxQH4gHNcPSJS53sUm0BdWvocGxNhX+MsZMnk2ddNsRnR98F69CZWWwskmw9H9mBDEbvbU9yKIMPhuLUAVFe1VTgaWFHSMhtlvopzPgSywhubm6/QXVULN9FtQTZSxWw4hRuLY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2017 10:15:44.7428 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB312 X-OriginatorOrg: ericsson.com X-IsSubscribed: yes |
Commit Message
Simon Marchi
Aug. 27, 2017, 10:15 a.m. UTC
As mentioned in the previous patch, we should avoid doing register reads after a process does an exec and before we've updated that inferior's gdbarch. Otherwise, we may interpret the registers using the wrong architecture. When a process does an exec with "follow-exec-mode new", a new inferior is added by follow_exec. The gdbarch of that new inferior is at first set to some default value, probably specific to the gdb build (I get "i386" here), which may not be the right one. It is updated later by the call to target_find_description. Before that point, if we try to read the inferior's registers, we may not interpret them correctly. This has been exposed by a failure in gdb.base/foll-exec-mode.exp after the previous patch, with: Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes) The call to "add_thread" done just after adding the inferior is problematic, because it ends up reading the registers (because the ptid is re-used, we end up doing a switch_to_thread to it, which tries to update stop_pc). The registers returned by gdbserver are the x86-64 ones, while we try to interpret them using the "i386" gdbarch. Postponing the call to add_thread to until the target description/gdbarch has been updated seems to fix the issue. As to why this issue was uncovered by the previous patch: what I think happened before that patch is that since we were updating stop_pc before switching to the new inferior, we were filling the regcache associated to the ptid (this worked fine as long as the architectures of the previous and new process images were the same). The call to switch_to_thread then worked, because the register read hit the regcache. Now, it triggers a register read, while the gdbarch is not set correctly, leading to the "reply is too long" error. If this is right, it sounds wrong that we delete and re-add a thread with the same ptid, and are able to access the registers from the deleted thread. When we delete a thread, should we clear the regcache associated to that ptid, so that the new thread starts with a fresh/empty regcache? gdb/ChangeLog: * infrun.c (follow_exec): Call add_thread after target_find_description. --- gdb/infrun.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Comments
On 17-08-27 12:15:33, Simon Marchi wrote: > As mentioned in the previous patch, we should avoid doing register reads > after a process does an exec and before we've updated that inferior's > gdbarch. Otherwise, we may interpret the registers using the wrong > architecture. When a process does an exec with "follow-exec-mode new", > a new inferior is added by follow_exec. The gdbarch of that new > inferior is at first set to some default value, probably specific to the > gdb build (I get "i386" here), which may not be the right one. It is > updated later by the call to target_find_description. Before that > point, if we try to read the inferior's registers, we may not interpret > them correctly. This has been exposed by a failure in > gdb.base/foll-exec-mode.exp after the previous patch, with: > > Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes) > > The call to "add_thread" done just after adding the inferior is > problematic, because it ends up reading the registers (because the ptid > is re-used, we end up doing a switch_to_thread to it, which tries to > update stop_pc). The registers returned by gdbserver are the x86-64 > ones, while we try to interpret them using the "i386" gdbarch. The analysis is great! > > Postponing the call to add_thread to until the target > description/gdbarch has been updated seems to fix the issue. This imposes an odd restriction on using add_thread, that is, we must keep in mind that we can't use add_thread until the inferior's gdbarch or target description is updated. The question in my mind is that why do we need to update stop_pc in add_thread? or can we remove stop_pc?
On 2017-09-05 12:37 PM, Yao Qi wrote: > On 17-08-27 12:15:33, Simon Marchi wrote: >> As mentioned in the previous patch, we should avoid doing register reads >> after a process does an exec and before we've updated that inferior's >> gdbarch. Otherwise, we may interpret the registers using the wrong >> architecture. When a process does an exec with "follow-exec-mode new", >> a new inferior is added by follow_exec. The gdbarch of that new >> inferior is at first set to some default value, probably specific to the >> gdb build (I get "i386" here), which may not be the right one. It is >> updated later by the call to target_find_description. Before that >> point, if we try to read the inferior's registers, we may not interpret >> them correctly. This has been exposed by a failure in >> gdb.base/foll-exec-mode.exp after the previous patch, with: >> >> Remote 'g' packet reply is too long (expected 312 bytes, got 816 bytes) >> >> The call to "add_thread" done just after adding the inferior is >> problematic, because it ends up reading the registers (because the ptid >> is re-used, we end up doing a switch_to_thread to it, which tries to >> update stop_pc). The registers returned by gdbserver are the x86-64 >> ones, while we try to interpret them using the "i386" gdbarch. > > The analysis is great! > >> >> Postponing the call to add_thread to until the target >> description/gdbarch has been updated seems to fix the issue. > > This imposes an odd restriction on using add_thread, that is, we must > keep in mind that we can't use add_thread until the inferior's gdbarch > or target description is updated. The question in my mind is that why > do we need to update stop_pc in add_thread? or can we remove stop_pc? Instinctively, I'd say that we should probably get rid of stop_pc, and instead get the same info through the current thread instead. I have a question for you, since you know much more about tdesc than me. Installing a default tdesc (e.g. i386) that is replaced just after with the right tdesc (e.g. i386:x86-64) creates the risk, like in this case, of using the wrong tdesc. Do you think it would be feasible (and a good idea) to instead have no tdesc installed until we figure out which one to use? We could then catch other operations that are done while the wrong tdesc is present. For now I'll push this patchset, so that it is in 8.1, but I feel it's just covering the real problem of having the wrong tdesc installed. Thanks for the review, Simon
On 2017-09-05 05:30 PM, Simon Marchi wrote: > For now I'll push this patchset, so that it is in 8.1, but I feel it's just > covering the real problem of having the wrong tdesc installed. Err, this should have said 8.0.1 and not 8.1.
diff --git a/gdb/infrun.c b/gdb/infrun.c index de0605f..25beaf4 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1211,7 +1211,6 @@ follow_exec (ptid_t ptid, char *exec_file_target) set_current_inferior (inf); set_current_program_space (inf->pspace); - add_thread (ptid); } else { @@ -1243,6 +1242,11 @@ follow_exec (ptid_t ptid, char *exec_file_target) registers. */ target_find_description (); + /* The add_thread call ends up reading registers, so do it after updating the + target description. */ + if (follow_exec_mode_string == follow_exec_mode_new) + add_thread (ptid); + solib_create_inferior_hook (0); jit_inferior_created_hook ();