From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id D12AB3858429 for ; Fri, 29 Jul 2022 09:24:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D12AB3858429 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26T9NJ2k005478; Fri, 29 Jul 2022 09:23:59 GMT Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2107.outbound.protection.outlook.com [104.47.70.107]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hmcvag0aj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Jul 2022 09:23:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CwrX8V27V7Da4rtzDmUrVc4YwQf3SVXXhlYnXKmFwRFt0ULwee1RdkSSIvBQ7lFVSMgBd/emXZnKJKs9eEPt0ycLiqIAKyavu23C3xfXUa1YeM4YNTSwh9aWvVDQiLpk6xg4/fGcd9+hugRLZXsYYHeSrFW6UnhfmI8oXLr/+hFbP+rJYGaJEnms4HYZuChKv2DaPq+zydMw5HbPc8+p01GApwZDriRVroQ6GppCjEI8Ol3XsdQGhEik+IqG0K4idXJcZYxkQ/g72EZrBAuI7PG6UQToemNAHhuHnVC+8vJehzEPWh3OoN/R4H0kqpbMLP/OAJF/18Krfpbv5m5LpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=1wCE8l4wAs8e5UT8BTUocej2BmE+d6K6sFjnsddwkQ0=; b=QRYewryLJX3w5Wfe+ER1pLEguGCtx+xBgZN82xZkmInFX+elSlW9TGEukhZRHqKfig9ps0rR8GoiBpFD6/PEPP/Ngmd8Gy9qTAHfE/PBzTnGshTcqQWGx6OiceYAVIVw8rSRZO7kPbQ1xihyh/Ap0qHIYlIoRQCgPdBbIJ7z3bd82I63aElukVhIktg3MKI1kQHNKTjwgWBgcvI/QS+gQ0YjA46LANm1NZamiZcFFSBcPj7aNMrhaNSgkWWB2msVTnJzRPjQMg8wzaKrEh15sVb62s8SS4ZalD6jdiCBCPc3ZPTAcm3lulX4ArDibGQaj/UJTAZdQ4QAOLl045gsPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ibm.com; dmarc=pass action=none header.from=ibm.com; dkim=pass header.d=ibm.com; arc=none Received: from CH2PR15MB3544.namprd15.prod.outlook.com (2603:10b6:610:5::26) by DM5PR15MB1356.namprd15.prod.outlook.com (2603:10b6:3:ca::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.11; Fri, 29 Jul 2022 09:23:56 +0000 Received: from CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::b831:7c28:bc34:6404]) by CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::b831:7c28:bc34:6404%7]) with mapi id 15.20.5458.025; Fri, 29 Jul 2022 09:23:55 +0000 From: Aditya Kamath1 To: Simon Marchi , Ulrich Weigand , Sangamesh Mallayya , "simon.marchi@efficios.com" , "gdb-patches@sourceware.org" Thread-Topic: [EXTERNAL] Re: [PATCH] Fix-for-multiple-thread-detection-in-AIX.patch Thread-Index: AQHYmFFabt4MyRx2wU+p6E9CkzDq6q2AXteTgAVEloCABQVYVIAEWHe7gAAQRwCAADTTAIAF1nNo Date: Fri, 29 Jul 2022 09:23:55 +0000 Message-ID: References: <49119016e80e58fafea0248887148aca3d1aef8c.camel@de.ibm.com> <841f0915-13a8-bbb3-07e6-54b5ff4293f1@simark.ca> In-Reply-To: <841f0915-13a8-bbb3-07e6-54b5ff4293f1@simark.ca> Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 48fa3d13-39e9-4bef-1de7-08da71440f90 x-ms-traffictypediagnostic: DM5PR15MB1356:EE_ x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1SD3MTu9iv4BtpdXlM2ECMrriZ7K+dWYdIdWo+G82X/jf4/pGw/eP/NyUs6LZHfKJ0ewWQtXHzvHZ+qgy32+8dM4EvQSaF4gpoPj3m5TY3c+o0MIAJ1oQSXJnNSHxAlK55tO+3O81r91C28pTjeLFuD5s71qQXyW77YvN2D+xRxA8jqNo5sTNKYfFpsoCyb4Vtqyp/kk35Je2qa6ICoFbe4UU6QYfqI+WyRJSr+inlJY9plgD3Xy7AExoYWTPLIP2D5EB8SqU2MRAvaCkSGFBFg+wNx6HP2Ckb/j4FWwEIAvbMi5YwA2WeHHN4RKspJG/taGav8Swysz2p8NTd+tTwQgGOJZ37qpcm2HuMXrjV0wU7oea9szctdRCzwkaRwHoViNDDusxvDEcLAqNaf8qN1Z+1QYP/erl/rVrAdVB4T7aW8WiWjGUHD+N+638ShEQIVtbrkWg/aBXfxrZd72SEs2QuYLElTAJy/zIrxR1hYIFUc6eci1hS1toeinCOve2+qtrbRicEM+lObijCdArfSYi2ZH3bpwDhkD0VhyEh3rsKiWODKJIperwVzXJyf2l5j3NCZKLGyifxRyRFwb8w5Agqdo8evvjbXiJoeKpu8W6IwozKyzt1e3WU6MJFWkpmVYxhga9LTW522ETDO/EU7j9lNwgvjDajFV1b64gd0r3cfMVOOcypetTgDGCjlKd0g2bcYrBhYMPwELeNkP/92YGDvLK9zF4tVJqQ1Wuhg/7VzCLv91dykaCFQ81lDjVa88xksdXqBmpyF3rhwAzkRMq5XecFyyrhdQPCo181vJZxDtjHcBFUmR/bYCnXZL x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR15MB3544.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(39860400002)(136003)(376002)(366004)(396003)(346002)(38070700005)(5660300002)(52536014)(8936002)(122000001)(38100700002)(99936003)(316002)(9686003)(7696005)(6506007)(53546011)(110136005)(71200400001)(478600001)(41300700001)(76116006)(66556008)(64756008)(66446008)(66476007)(8676002)(66946007)(91956017)(83380400001)(186003)(2906002)(33656002)(19627405001)(55016003)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kTsnTegpZaqAKKY8awrBSHhsXxP2G+KPavlYiiYG0CbVZEvwfRj+G8L7ksaf?= =?us-ascii?Q?7flIFQA2sm1SxgUKC6YVFo4ZyDZE7tqQ87ewjHJ2t6cA/95tBZF6Js2t4mYM?= =?us-ascii?Q?ndMldFYA2Mn9yAOcw1A9Dr3YrrKPUFGYL7ByoTwWsMreg9kE/fTXFynRWcdp?= =?us-ascii?Q?VvPoAv6l963Lh8LjRu/yR/EDUyPtCB+SpLwN9JOvjgs9CanZn86gO4DrLAlr?= =?us-ascii?Q?FLagpqvjeso15XiZAXyMQu2cS5bEyAacJk01GAGa62/YpeNaK7Lg/MFmFPus?= =?us-ascii?Q?ZgcQDsMzgU851BWUu9BhJRwGKbuizXVHgT0xIJ/29dPfAUnBMKoIAM01wT71?= =?us-ascii?Q?P+RMmsasz2IIgsZw1LH3UGjfsjEnCl87aol6lWKjrkyqU10hX9GYUptwg64J?= =?us-ascii?Q?0sAZ78000MUfXb0rnAa56r17D78FfdLdHS8/SAtTJLzxkhEW3x2POmpzCQrw?= =?us-ascii?Q?iV3fPdZuluWFxi/IMq389s3EKbCBEXTdpRDsxGk1sZg3yxHDGIfNxcEdbhXe?= =?us-ascii?Q?enYMz89lhtP8w4LaY3O1LuvpmbHzQhQFiRPafVJHJmztsdpzfEQXnjwVJMtY?= =?us-ascii?Q?eY4jsrYHb/tXRH6PR9q5bnsNW1QIrvSRdgvADqCJFWr93ZuVLJeRvESAAOtr?= =?us-ascii?Q?EAAJ9eAtYwweVISl34+Su09eyTS26uLrWdi+i6Pp7JLcBthzqZyIzcXVT44E?= =?us-ascii?Q?Ff54ErBg3l46caIjCET2BABbEF/sjxRMdm1doB0uK+2cZdjnGdGUJ5TQxQOp?= =?us-ascii?Q?33AMUoLWLeXCWLgvd3hbBxogbIb8iwh9aA+QtgsQJh2T6zvQiqlKh9Qju6I2?= =?us-ascii?Q?0gABy0o3tbRKaU8QfOe39M95c1GOUogms5mFrMhH9WOg4o6Mts4b9FzB6G3l?= =?us-ascii?Q?oq7QpU/a8bhGxNSkfaBrLZndS+oTS6DGLRIH+PuhitWajbTJPgoy7kPltDyu?= =?us-ascii?Q?Mf7sSAKS6QQumLDuxdZqMpgtZjEsOmQmG+ZmmSSSCSWYac+Kjw2Xqjxc7zXA?= =?us-ascii?Q?1tbGQS7jN3GfMKtBXb2EUpoI92Jroq8tvHVVyOdCk9ErPHADAyhMSt6Jklil?= =?us-ascii?Q?AKj8nrcsOHuRV8AP7p/iS5uuOLA/uynfnlrj2lZQ+2iE/JQqi7YZe6Vc7tRj?= =?us-ascii?Q?NEibPo4SeEfnQSIuwB1sZBAUmHNvz2p0621bR8vkFjklEXTMACaWOJklZpBV?= =?us-ascii?Q?3RNtTmjvLUh+R3q5srraW/uokYacynfx0y+I9yh3hdW5cBeZ7oLY1+xp0+rS?= =?us-ascii?Q?P6MAkK7Hm+JuqtOU3vl1XIuzbQ4ke9XTvXSOaOkFpLlujgkjS4zebtaUIdXs?= =?us-ascii?Q?tRzbgKlJfPs+WJ0Uj8hMaeC4Ps00q9OWkFm+5dw+zf7Mf4l62TUZ0+wKBQws?= =?us-ascii?Q?QDqUFDA/LKAn2t9Tf+Tpo4t5R4/Q9PMuWoBLuqEp0lGstJx/A0MBw3NaDrFN?= =?us-ascii?Q?QUVPSaXVpWI9RTOxWuy8osjWUvG455l27U9PiSpTwPkfZKQSaMpOqPB7wo1o?= =?us-ascii?Q?N0LV4ESJN+GODC1I0yUq5SU7RfDqktQ+4JA5SzBmv3IcIPX9Yg/ET0W22Jun?= =?us-ascii?Q?XvB2ZG+SCfdRc0XVLy6Fk1LqTr8K5lPuzw9l8rOt2/JaM1JV9VPtYaYW0te5?= =?us-ascii?Q?PJtjeOMtNvzpZTbdvWrADJv4/rkUNthLfnmAJIlnOZt3?= Content-Type: multipart/mixed; boundary="_004_CH2PR15MB3544EBFF8732F7611C72BA2AD6999CH2PR15MB3544namp_" MIME-Version: 1.0 X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR15MB3544.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 48fa3d13-39e9-4bef-1de7-08da71440f90 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2022 09:23:55.9008 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcf67057-50c9-4ad4-98f3-ffca64add9e9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: T5Fi/IXRQU1GPqlxOjmWeT3okvoFo0Jnal67Q8zpu3UL536Omj3bxOsDu9HmMbZ2hXkkW8cATUrD1RYuy4+nqw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1356 X-Proofpoint-GUID: pWcg3AmV-J36l6JAVf3z6WLr18YesaMx X-Proofpoint-ORIG-GUID: pWcg3AmV-J36l6JAVf3z6WLr18YesaMx Subject: RE: [PATCH] Fix-for-multiple-thread-detection-in-AIX.patch X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-07-28_06,2022-07-28_02,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 malwarescore=0 clxscore=1015 mlxlogscore=999 mlxscore=0 spamscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207290038 X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, HTML_MESSAGE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2022 09:24:06 -0000 --_004_CH2PR15MB3544EBFF8732F7611C72BA2AD6999CH2PR15MB3544namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I thank you for the feedback that was given. It was a nice insight. Please find attached the new patch. [See Fix-for-multiple-thread-detection-= in-AIX.patch ] However, there are a few things that we had to look in further to what was = suggested. Here are my explanations to what was suggested. > I still think the proposed fix isn't really ideal. Can you instead > try to *temporarily* (i.e. using a scoped_restore) set up inferior_ptid > in pd_activate() before calling pthdb_session_init(), with a comment > explaining that this is needed for the callbacks? This is a nice idea Ulrich and Simon. However, let me take a case of a prog= ram creating 2 threads plus OfCourse having a main thread. Let's say the pr= ogram creates the first thread. This solution works fantastic. So, what is the problem with it?? We have our pd_active set to 1 in pd_act= ivate(). So, the next time we get into the wait() of aix-thread.c on an eve= nt of a new thread, what happens is since pthread debug library is initiali= sed we need not get into pd_activate() again to initialise. Therefore, this= condition : if (!pd_active && status->kind () =3D=3D TARGET_WAITKIND_STOPPED && status->sig () =3D=3D GDB_SIGNAL_TRAP) was made... We directly go to the pd_update().. Since the sync_threadlists(= ) also have pthread debug library functions and our current thread is also = null, we end up syncing threadlists with null thread which means our debug= ger will not reflect the new threads at all or if it does we will get an as= sertion saying "Assertion `ecs->event_thread->control.trap_expected' failed= " simply because only the thread which is allowed to step should create a t= rap and we on a creation of new thread said to the gdb core that null threa= d is the one who raised the event of new thread creation and hence the trap= .. So, what can be the solution?? It is great if we create a scope and tempora= rily switch our thread just before you pthdb_session init() in pd_activate(= ) whicj takes care of session initialisation and just before the sync_threa= dlists() in pd_activate() post which sync threadlists() can give us the rig= ht thread who caused an event to the gdb core .. Kindly see the patch for the same with comments and inferior_ptid.pid () sp= ace correction is also made which I needed to as per Simon. Let me know what you think, if not let's push this so that AIX folks can de= bug with multiple threads. ---------------------------------------------------------------------------= ------------------- >>To avoid this kind of problems, you can temporarily >>switch thread (using scoped_restore_current_thread + switch_to_thread), >>which will set all the current stuff mentioned above. But sometimes >>this isn't possible, especially in thw wait method, because there isn't >>always a thread_info for the ptid you are handling yet, so you can't >>switch to it. Since you all are more experienced than me, I am sure the future issues and= solutions will be brightly more visible to all of you than me and I would = love to learn that.. Having said that let me assume you might be thinking o= f a fork() event where in case we return the child process ID and we switch= _to_thread(current_target, child_ptid) we might get an assertion saying inf= ->thread does not exist and rightly so.. That is where the APIs or function= s like ourstatus->set_forked(child_ptid) come in picture where we can pass = a new process info and then return a parent process ptid who has a thread f= rom beneath->wait to aix_thread:wait() and that way we won't face this issu= e of having an inferior with no thread when we use switch_to_thread(current= _target,ptid) in AIX for the time being at least.. Hopefully we are thinking in the same terms and the solution for multiple t= hreads is fair. Have a nice day ahead. Thank you, Regards, Aditya. ________________________________ From: Simon Marchi Sent: 25 July 2022 21:00 To: Ulrich Weigand ; Sangamesh Mallayya ; Aditya Kamath1 ; simon.marchi= @efficios.com ; gdb-patches@sourceware.org Subject: [EXTERNAL] Re: [PATCH] Fix-for-multiple-thread-detection-in-AIX.pa= tch On 2022-07-25 08:21, Ulrich Weigand wrote: > > Aditya Kamath1 wrote: > >> The cause of the bug :- Since, for the GDB core we are >> switch_to_no_thread() i.e. we do not have a thread till we return the >> pid from the wait() there is no thread. So, when a call is made from >> pd_activate() in wait() of aix-thread.c, to pthdb_session_init() we are >> going to recieve PTHDB_NOT_THREADED. > > Thanks for the explanation. I wasn't aware the use of > inferior_ptid happens in some of callback routines used > by the pthdb_session_init() library routine. Thanks, me neither, but it makes sense. > I still think the proposed fix isn't really ideal. Can you instead > try to *temporarily* (i.e. using a scoped_restore) set up inferior_ptid > in pd_activate() before calling pthdb_session_init(), with a comment > explaining that this is needed for the callbacks? That sounds like a good idea, this way, from the point of view of the caller of pd_activate, pd_activate does not care about global state. That's how we can do baby steps towards relying less on global state implicitly. The next step could be to try to make each individual callback switch to the right global context, based on what they need. You just need to be careful, some parts of GDB expect inferior_ptid, the current thread, the current inferior and the current program space to be sync'ed. If you just set inferior_ptid, you need to make sure to only call functions that use inferior_ptid, not the other current stuff. There is not practical way to know this, you have to carefully inspect what is called. To avoid this kind of problems, you can temporarily switch thread (using scoped_restore_current_thread + switch_to_thread), which will set all the current stuff mentioned above. But sometimes this isn't possible, especially in thw wait method, because there isn't always a thread_info for the ptid you are handling yet, so you can't switch to it. Given the AIX target only supports one inferior for now, the current inferior and program space should be correct. But to support multi-inferior, it will be important to keep that in mind. You might have to switch to the right inferior in addition to setting inferior_ptid in pd_acticate. This hunk in the patch: diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c index 4c9195a7f12..91466a17647 100644 --- a/gdb/aix-thread.c +++ b/gdb/aix-thread.c @@ -976,7 +976,7 @@ pd_enable (void) /* If we're debugging a core file or an attached inferior, the pthread library may already have been initialized, so try to activate thread debugging. */ - pd_activate (1); + pd_activate (inferior_ptid.pid()); } looks right to me (except the missing space before the parenthesis). It looks like an oversight in my "gdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid" patch, I forgot to update that call to pd_activate. Note that the old parameter to pd_activate was SET_INFPID, and if set, pd_update would change the current thread to reflect the thread ptid, if thread debugging was enabled. The current code no longer does that. If that was important, we can re-introduce it here: make pd_enable switch to the thread with the ptid returned by pd_activate. Simon --_004_CH2PR15MB3544EBFF8732F7611C72BA2AD6999CH2PR15MB3544namp_ Content-Type: application/octet-stream; name="0001-Fix-for-multiple-thread-detection-in-AIX.patch" Content-Description: 0001-Fix-for-multiple-thread-detection-in-AIX.patch Content-Disposition: attachment; filename="0001-Fix-for-multiple-thread-detection-in-AIX.patch"; size=2076; creation-date="Fri, 29 Jul 2022 09:18:29 GMT"; modification-date="Fri, 29 Jul 2022 09:19:16 GMT" Content-Transfer-Encoding: base64 RnJvbSA5MWJlNzgzYTBlZGU5ZmQxZmQ2ZjU1MzE1Y2Q1OTgwM2QyOTEwZDc4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBZGl0eWEgVmlkeWFkaGFyIEthbWF0aCA8QWRpdHlhLkthbWF0 aDFAaWJtLmNvbT4KRGF0ZTogRnJpLCAyOSBKdWwgMjAyMiAwMzozNjoyMSAtMDUwMApTdWJqZWN0 OiBbUEFUQ0hdIEZpeC1mb3ItbXVsdGlwbGUtdGhyZWFkLWRldGVjdGlvbi1pbi1BSVgKCi0tLQog Z2RiL2FpeC10aHJlYWQuYyB8IDI4ICsrKysrKysrKysrKysrKysrKysrKy0tLS0tLS0KIDEgZmls ZSBjaGFuZ2VkLCAyMSBpbnNlcnRpb25zKCspLCA3IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBh L2dkYi9haXgtdGhyZWFkLmMgYi9nZGIvYWl4LXRocmVhZC5jCmluZGV4IDRjOTE5NWE3ZjEyLi42 OGFhZDI4MmVlNyAxMDA2NDQKLS0tIGEvZ2RiL2FpeC10aHJlYWQuYworKysgYi9nZGIvYWl4LXRo cmVhZC5jCkBAIC04ODcsOCArODg3LDE1IEBAIHBkX3VwZGF0ZSAoaW50IHBpZCkKICAgc3RhdHVz ID0gcHRoZGJfc2Vzc2lvbl91cGRhdGUgKHBkX3Nlc3Npb24pOwogICBpZiAoc3RhdHVzICE9IFBU SERCX1NVQ0NFU1MpCiAgICAgcmV0dXJuIHB0aWRfdCAocGlkKTsKLQotICBzeW5jX3RocmVhZGxp c3RzIChwaWQpOworICAKKyAgLyogVGhpcyBpcyBuZWVkZWQgdG8gZWxpbWluYXRlIHRoZSBkZXBl bmRlbmN5IG9mIGN1cnJlbnQgdGhyZWFkICAKKyAgICAgd2hpY2ggaXMgbnVsbCBzbyB0aGF0IHRo cmVhZCBsaXN0cyBzeW5jIHdpdGggdGhlIGNvcnJlY3QgY3VycmVudAorICAgICB0aHJlYWQuICov CisgIHsKKyAgICBzY29wZWRfcmVzdG9yZV9jdXJyZW50X3RocmVhZCByZXN0b3JlX2N1cnJlbnRf dGhyZWFkOworICAgIHN3aXRjaF90b190aHJlYWQgKGN1cnJlbnRfaW5mZXJpb3IgKCktPnByb2Nl c3NfdGFyZ2V0ICgpICxwdGlkX3QocGlkKSk7CisgICAgc3luY190aHJlYWRsaXN0cyAocGlkKTsK KyAgfQogCiAgIC8qIERlZmluZSAiY3VycmVudCB0aHJlYWQiIGFzIG9uZSB0aGF0IGp1c3QgcmVj ZWl2ZWQgYSB0cmFwIHNpZ25hbC4gICovCiAKQEAgLTkxMSwxMCArOTE4LDE3IEBAIHN0YXRpYyBw dGlkX3QKIHBkX2FjdGl2YXRlIChpbnQgcGlkKQogewogICBpbnQgc3RhdHVzOwotCQkKLSAgc3Rh dHVzID0gcHRoZGJfc2Vzc2lvbl9pbml0IChQRF9VU0VSLCBhcmNoNjQgPyBQRU1fNjRCSVQgOiBQ RU1fMzJCSVQsCi0JCQkgICAgICAgUFRIREJfRkxBR19SRUdTLCAmcGRfY2FsbGJhY2tzLCAKLQkJ CSAgICAgICAmcGRfc2Vzc2lvbik7CisJCisgIC8qIFRoaXMgaXMgbmVlZGVkIHRvIGVsaW1pbmF0 ZSB0aGUgZGVwZW5kZW5jeSBvZiBjYWxsYmFja3Mgb24gY3VycmVudCAKKyAgICAgdGhyZWFkIGFu ZCBpbmZlcmlvcl9wdGlkLiAqLworCQorICB7CisgICAgc2NvcGVkX3Jlc3RvcmVfY3VycmVudF90 aHJlYWQgcmVzdG9yZV9jdXJyZW50X3RocmVhZDsKKyAgICBzd2l0Y2hfdG9fdGhyZWFkIChjdXJy ZW50X2luZmVyaW9yICgpLT5wcm9jZXNzX3RhcmdldCAoKSAscHRpZF90KHBpZCkpOworICAgIHN0 YXR1cyA9IHB0aGRiX3Nlc3Npb25faW5pdCAoUERfVVNFUiwgYXJjaDY0ID8gUEVNXzY0QklUIDog UEVNXzMyQklULAorCQkJICAgICAgICAgUFRIREJfRkxBR19SRUdTLCAmcGRfY2FsbGJhY2tzLCAK KwkJCSAgICAgICAgICZwZF9zZXNzaW9uKTsKKyAgfQogICBpZiAoc3RhdHVzICE9IFBUSERCX1NV Q0NFU1MpCiAgICAgewogICAgICAgcmV0dXJuIHB0aWRfdCAocGlkKTsKQEAgLTk3Niw3ICs5OTAs NyBAQCBwZF9lbmFibGUgKHZvaWQpCiAgIC8qIElmIHdlJ3JlIGRlYnVnZ2luZyBhIGNvcmUgZmls ZSBvciBhbiBhdHRhY2hlZCBpbmZlcmlvciwgdGhlCiAgICAgIHB0aHJlYWQgbGlicmFyeSBtYXkg YWxyZWFkeSBoYXZlIGJlZW4gaW5pdGlhbGl6ZWQsIHNvIHRyeSB0bwogICAgICBhY3RpdmF0ZSB0 aHJlYWQgZGVidWdnaW5nLiAgKi8KLSAgcGRfYWN0aXZhdGUgKDEpOworICBwZF9hY3RpdmF0ZSAo aW5mZXJpb3JfcHRpZC5waWQgKCkpOwogfQogCiAvKiBVbmRvIHRoZSBlZmZlY3RzIG9mIHBkX2Vu YWJsZSgpLiAgKi8KLS0gCjIuMzEuMQoK --_004_CH2PR15MB3544EBFF8732F7611C72BA2AD6999CH2PR15MB3544namp_--