From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id BC8A83886A3C for ; Thu, 8 Dec 2022 10:28:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BC8A83886A3C Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ibm.com Received: from pps.filterd (m0098417.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B8A7udA005898; Thu, 8 Dec 2022 10:28:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=pp1; bh=3bnHCMedII3WQsJWdnqJRGeDm4fM8VESiszmIvRd7nU=; b=glMyalOvgStIHm7OeTY0TvDDStRP1iqEuE+I3wvRCdEdHazrFieNGQTiO/loC7fJzGop WJasP8kI1RUnqkrspmSNJ6WHm0L0ZsKWeyYhIv5u3UZF9O5B8dED2NnhDE9UhKSmL8q6 z/iIU+6eKrxPSx9hpHGrdm5/V3WjnJ5CVu8iJP4WJldlAWZIFWHqYYhEY2Rpq1GlpF71 H8DoRoX1RJSxq16x9DoiI3VtsFWkT75s4wxapWuq6taFJB2Bvx717zXsw84Lx9cirFBS yj1EznxEu1Rg+g9sH6Igdqr7NntIrVotfuN6EmgaXMRkdOvmiI4Lt99DdgL6qBd851FV yQ== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2177.outbound.protection.outlook.com [104.47.55.177]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3mbdwd0j40-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Dec 2022 10:28:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OdHBKlHsWLVBy5B/fUW7GAMLRmRfGBEVrnlLtLlIfZrhUaCJe32XFKnaPQ6m3KASFk6JpOMjyOToqcCGF6l5J+luCI1WLeWC0xfNtqwJYNZ90tSFD4Qjal3vaUAKRW3Pm89cB4WNRxDe2mlRZPAvSF3EtGWLbOlLUVYAHdgkBUoQpszfpctSbMROchjWcrMqkPqQaM+hkmcRolSy63snUWpBSpsyzqAhGLes9IkN9GXJg0j527u4TTYKS0SuRCf7dVjNGKG4jh8zwnNMSc+LrjHvHUi+a39hYeSjYKDdg6LKqdG5ZkOILiGYq3thMDh35pIl9f0N4WDJGbrHgC1FZg== 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=VNrpqq29Zqiiy8B1eLuyiL2sUDoeU58XR+6Eoo1QxMo=; b=fzB+PFXaS0rtaaDvWOQoB+ZLJSMN8yd3vS3a7w9UyrRLpPw24kxkyrS0FGXghOGPY8z1QSApSh8GB7tJ66acE9mdTkJGQd5Eezks5t10qhLpOPHTXoTae/1A3C7EFyagzZZU2ksaD05Wch2PknC868w/vHXHgJ2QtESDP1QvOsxy8KF1sEeSZMDVWzYl28eVXbY8NnAAkN1LP+vLGYME6LBMPQL4GOHuJ2nbBUH0opK7ajdOt221nSOfA7DMOMT7phV2ZdOXQckd2coLIhWTDRvw2rHaaxAkjaYD/AOU/3CTX/cLTXqfdXLqZZI0ZHTsHlm5qWEpW7hge+HhPIWMaQ== 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 DM6PR15MB3765.namprd15.prod.outlook.com (2603:10b6:5:294::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.11; Thu, 8 Dec 2022 10:28:32 +0000 Received: from CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::47c1:1108:4041:7d32]) by CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::47c1:1108:4041:7d32%7]) with mapi id 15.20.5880.014; Thu, 8 Dec 2022 10:28:32 +0000 From: Aditya Kamath1 To: Ulrich Weigand , "simark@simark.ca" , "gdb-patches@sourceware.org" CC: Sangamesh Mallayya Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch Thread-Topic: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch Thread-Index: AQHY6DximDPpCqTL9kGyFvcEZokFBq4jlIiAgBFljYeAAA2HgIAIORaygAMrdQCACMPAdYADi8KAgAAbf+aAABUYgIAADhDtgAjHItiAAgYnAIACq/WKgAVsGwCABC6K8g== Date: Thu, 8 Dec 2022 10:28:31 +0000 Message-ID: References: <0866c91331b08f2870fad6e6a13fbcd1a9823b48.camel@de.ibm.com> <5df6ab523034d1997ffda5bb06c3bd87777dcccb.camel@de.ibm.com> <0dba07cfad3da44c0281c53702d73f807bca7d06.camel@de.ibm.com> <5956432ab1e0eedc8f65e01d3793a80ccf3a3a1f.camel@de.ibm.com> <139ff3da5e35905c963869569bebf280733740c2.camel@de.ibm.com> <8302c3570292b864ab21176e58bdee546f6e4544.camel@de.ibm.com> In-Reply-To: <8302c3570292b864ab21176e58bdee546f6e4544.camel@de.ibm.com> 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-traffictypediagnostic: CH2PR15MB3544:EE_|DM6PR15MB3765:EE_ x-ms-office365-filtering-correlation-id: 4280fb6d-6911-4a8e-fd38-08dad906f470 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: svNaeMhg39YNnqTC5N1Pm+A8uSQwgJmtf8dwDFrnzj69kSd/82AZAlaQzi0APNMSOCImKrIUmseF7coNp33VmeuFuv+JRGRHRacxD5XIlh3yIeFeMxFOG54nNb70C2SXUG15U5as1JyMO0CQjwoiNAublAoV9dPCbCZZy7I/BEnQ4aAfp2DeAbjc1+ULFjsGI1lhs/OA8RhP1+HhOJnW/AdMm2teqYFA5B7DRdXuNqPomSL3CFWkUOmwJkujm4ygwNdDAFccxZNVfowSV6ucZrO4tjkHIc/jGcGEqpVbZuBIVMZ+gFFP1a9M2NHZ2mVru6wex4XuCAH+aDweufUdnHL7I7/mpuz9cDmI945oTpsB5dx/4zEepBlD6QFpxQdM5oH4d9cKEdi3bkFeK5ZnyEgHEAfVHeq2dV2JuQmHMWTbzCm5sbskYOVV6Wg8uKsBCEOGfMcL6uO5w9Bhud4cNqqMky5Nfrp8LYLZH5sslW8MFaawTQQR6GWmRoo9Z7uEh8MTn06K5FLYIAcSE/SshlLpCZXsn0b8INi+jVsADRiuC8ieeqqw9PR7J0Ksl+jJDRRL4lxpOln/EYLqGtBX/hFU3yyRhvxk/aUrg5Hn1c1CJxUiXkfGvGxb3uDp4WMv3HsTBEwneR9uqK+rzSegEjY1rioEV/qI8TR2QV8eN2R69TWP0Cq+98vryA6Io/pnXVBFE7CokcFp82fgUJTOB7IbSmX4Lv1ldr93pB4rUMI= 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:(13230022)(136003)(39860400002)(346002)(376002)(396003)(366004)(451199015)(19627405001)(38100700002)(66946007)(122000001)(166002)(41300700001)(2906002)(38070700005)(52536014)(83380400001)(30864003)(86362001)(99936003)(64756008)(316002)(66446008)(33656002)(110136005)(8676002)(478600001)(66556008)(91956017)(5660300002)(66476007)(76116006)(71200400001)(55016003)(7696005)(4326008)(8936002)(6506007)(53546011)(9686003)(186003)(559001)(579004);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/PRNVH9+eNjBhBBWs5JIUWqaD6xbhirxbXeQZUP/6rytK31fEAt/JqfkWOZ7?= =?us-ascii?Q?8SFoZlNg20NdoUkRYiZNkBkbmWinTJOHanmoSV9wv5wHLsualVLzk0eL3cxZ?= =?us-ascii?Q?RLafPfIAwGLCZoD4DYqqa7epaFHOBiegia/WMMRC7hsZuOQc6fPcZclNVUYu?= =?us-ascii?Q?itWpuN3QSZvpDmYUAJVneChIZqfIQK5rN4zro6Hfz2+ZnYFcsgrmhZvne/5t?= =?us-ascii?Q?YMbsGTvbPBIDlLqFoD/1Jw7gExBFKhTW6b7A/tTlqapG/8pFtrY1LDpX4EtS?= =?us-ascii?Q?BOkUXavQBo0m2KeYLmFDOx0FhX4Hywjm0ZM2OdGvz46wDxwZRAfX3+SPKhNI?= =?us-ascii?Q?GwOgnzM6V6iBhs3KgSMZJ6e6VQL2ewfaPO+MvpWxCW4ia1AcCs1LOL3vxabm?= =?us-ascii?Q?1Rp+ZG7f6FFr1gE1uLpfYUroxsN3P5zs7vN16JYGrBMACYdF+/DHZfyVCgVQ?= =?us-ascii?Q?UAveho32DS2qfZ8/aTTIJbiG1s51skBtPvfXo4CT4xaMAea2W9Ly77zZBGle?= =?us-ascii?Q?+gWp3aEAX8QZ0MUtj4GaGjhonXG2oa86KE8sAO/bC2/0odrn3iXtURfYpN4L?= =?us-ascii?Q?qx0vRP/aV20ZT3H57uwBR0fGD4Na1Ogb+JMYYy3GUzLVnydPPxS+c7KxXbQm?= =?us-ascii?Q?oL99tR/NAl7T+sCkeUN+bnm0Ztdl9XqvR3w/YWP+UCKE3ttK1bDXMq64rGgv?= =?us-ascii?Q?hjwQpkttn595ZDbUTspcZyqmFStxgu6A/9XVmCYK/kkoKZN8QkEcKJk5kikD?= =?us-ascii?Q?YPg6DBcD10Kt+QIeqNXcoys8kWGsvRKhDbFHVvNE79l46L3XljmDl7y6RQ1G?= =?us-ascii?Q?PJKhX7K34IDI3W+EoB2xwOn1rzNIUllUiIt16RkujC8w2IyZbtQBHAx46pkF?= =?us-ascii?Q?y4GSmyHzzVoMpvOKizfnspBRyW7O21GNpezZdtq2qOR8+irpePfMJEWIpNTH?= =?us-ascii?Q?T0cZIl2eCQihlmQ5Q4RuTZ2rPq9eIQo4fjU9XUIFiZkeitM6OdofubZyHUDd?= =?us-ascii?Q?Ns9RHrBAGtqJ+eEvwI5bSPn3meiFt2fSfEkpe6nHYo1H2v1mHwkEGLrTpjxM?= =?us-ascii?Q?h3rk/eNMjft2bKr5PFn9FJLkC9YKfSKsR+hlhAA/ZKaHhX2QNUVXza6JzlH7?= =?us-ascii?Q?GIkqPnJNnsC8i+RKSAABPraeHTRhw+hVVVBZnQLdbQAoQ7vy3bQTz1hz3EZ3?= =?us-ascii?Q?idXNzlt0F6fVUwPVYASnNv0Yjz/hvF1WlW8lacUyk9pTEhHu3ddSNh3Rlds2?= =?us-ascii?Q?fs1+j5OzwKNdiLF8SkS14soODD6TOWgvz19kiDbGu3fUChayxFyzc1UxvC7x?= =?us-ascii?Q?EkZKGdzND++cQFe829vquDPrXmUkPP+eNmSM8lbIBIimYWM5jDF2zXZhtMJT?= =?us-ascii?Q?6YeugC7vR2cgEU4dO7F1pYTgqWej4J6NCOqEXMEQjyJ1YgHkgffuCLBSNlCG?= =?us-ascii?Q?LXL63y4N08ITjLEIOB6Io0pvjC4Nbllo4eYWTNwydfXgrotl94IceA1ik+zt?= =?us-ascii?Q?Osbs2IzWJAjXTCXBvg/HS5zPiVumZeuuLOBR7B7Fhak0gf5Cin8X+Iu83IiY?= =?us-ascii?Q?9lh9FV0evpef4wkdwWtg0TVYGF8DkZiIiRjzKUIOUDS4CSwDDhfoCbUlRMPo?= =?us-ascii?Q?SIpUcv04qYXSs52HVJnM11IWIeB0TTm2zffBGeVXqJvp?= Content-Type: multipart/mixed; boundary="_004_CH2PR15MB35447EE88C64F7F36A0C61F5D61D9CH2PR15MB3544namp_" 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: 4280fb6d-6911-4a8e-fd38-08dad906f470 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2022 10:28:32.0110 (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: MXlAjOV23N/48Xjw+xeeHo4s5PbecM1HUtWP5B8NIbgIhfbTLxCrGsfZpwklgtmghUCOPAX8OIlmEEvQDu5ibA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB3765 X-Proofpoint-ORIG-GUID: sA109IacO0vV7TfAvRQkrbzUV4Icu878 X-Proofpoint-GUID: sA109IacO0vV7TfAvRQkrbzUV4Icu878 X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-08_04,2022-12-08_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 bulkscore=0 clxscore=1015 malwarescore=0 adultscore=0 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 priorityscore=1501 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212080077 X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --_004_CH2PR15MB35447EE88C64F7F36A0C61F5D61D9CH2PR15MB3544namp_ Content-Type: multipart/alternative; boundary="_000_CH2PR15MB35447EE88C64F7F36A0C61F5D61D9CH2PR15MB3544namp_" --_000_CH2PR15MB35447EE88C64F7F36A0C61F5D61D9CH2PR15MB3544namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ulrich and community, Please find the new patch [See:- 0001-Fix-multi-thread-bug-in-AIX.patch ] I have moved get_signaled_thread () function which tells us which is the ke= rnel thread that caused an event due to which the debugger had to wait to r= s6000-aix-nat.c. So, we figure out which kernel thread might have caused an event in the rs6= 000-aix-nat.c code itself. If let us say the main thread is pthreaded or a = new user thread is being created or user thread is deleted, then I have tak= en care of what to return in sync_threadlists () code itself. >>So, if you observe output 3 or 4, the program first multi threads, >>I mean thread events are handled first and then the threads fork. >>So, when this happens, I cannot return ptid_t (parent_pid). If I do >>so, the GDB core will treat it as a new process and add it in my >>threadlist as say process 100 despite existence of 'thread 1' >>representing the same. So, I need to correctly send which thread >>did the fork () event or which thread of the process is the one who >>gave birth to a new inferior process [say 2 or 3 in output 3 below], >>I mean which thread caused the mult process event when the process >>is mutli threaded. This has to handled here as control from target.c >>comes directly to rs6000-aix-nat::wait and not through >>aix-thread.c::wait since fork () is a process event.. >So this last bit seems to be the problem. Could you elaborate on >what the exact call stack is? I thought once the thread layer is >initialized, calls to ::wait should always go through it ... Kindly see the backtrace sections * BT:- Thread_wait [which is on a thread event like new thread born or = main process is pthreaded], * BT:- Post thread wait in rs6000-aix-nat::wait [which is the beneath = ()->wait () in aix_thread_target::wait], * BT:- If direct rs6000-aix-nat::wait [ where in output 3 and 4 {below = in this email} you can see it will directly come to rs6000-aix-nat.c if the= main process after having threads forks or uses a fork () call ] pasted be= low in this email. >So the way this works e.g. on Linux is that the process layer handles >both processes and the *kernel* aspect of threads, while the thread >layer handles the *user-space* (libc/libpthread) aspect of threads. >In terms of the GDB ptid_t, this means that both the "pid" and "lwp" >field are "owned" by the process layer (which would be rs6000-aix-nat.c >in your case), while only the "tid" field is owned by the thread >layer (which would be aix-thread.c). >Linux does that because it allows correctly debugging programs that >only use the kernel threading capabilities without using libpthread, >e.g. by directly calling the "clone" system call and not "pthread_create". >Such threads won't be in the thread list managed by the user space >library, but are still handled by the process layer in GDB, tracked >as lwp without associated tid. >Not sure if something like that is even possible in AIX. If it does >make sense to handle things similarly in AIX (one other reason would >be ptrace commands that require LWPs, e.g. like the VSX register >access you had in another thread), some code would indeed need >to move, e.g. everything related to accessing *kernel* threads >(fetch_regs_kernel_thread etc.), while code that accesses *user* >threads via the libpthread accessors (fetch_regs_user_thread etc.) >would still remain in aix-thread.c. With this patch I have moved all my lwp checks in rs6000-aix-nat.c file and= user thread things in aix-thread.c.. Yes, this will help us in the vector = patch. >>While debugged in depth last two days I realised our pid_to_str >>is needed in rs6000-aix-nat.c as control comes here in search of it. >>If it doesn't GDB treats all threads as process. >This is again very suspicious. We obviously already have >threads, so the thread layer should be initialized. This >means that any "pid_to_str" call should go through the >*thread* layer (implementation in aix-thread.c). If that >doesn't happen, we should understand why. (This may be the >same problem that causes "wait" to be called from the >wrong layer, as seen above.) Kindly check the backtrace section [ BT:- pid_to_str stack ] below this ema= il. So, what is happening is a thread event will come through threads and a= process even will come through process layer. For example, while I press a= n interrupt key [Ctrl+c] in a multi process scenario, for the GDB core know= ing which process is needed. By looking at the stack, it is built assuming = the target will figure out the kernel thread that eventually caused this ev= ent in the process layer. Secondly kindly look at aix-thread.c:pid_to_str. We have a beneath()->pid_t= o_str () there in case the process is not threaded. So, we need one in the = rs6000-aix-nat.c. aix_thread_target::pid_to_str (ptid_t ptid) { if (!PD_TID (ptid)) return beneath ()->pid_to_str (ptid); return string_printf (_("Thread %s"), pulongest (ptid.tid ())); } >>I have added an assertion here just >>to be sure. I get what you are thinking. >Having an assertion is of course good, but it isn't obvious to >me that this never can be hit. So, while I ran a few unit tests I did not find any case where we might end= swapping the pid. So, I added the same so that if anyone hits this in the = future, we are aware and can change accordingly. >The point is if GDB stops because the target received a signal, it >should automatically switch to the particular thread where the signal >was in fact received. I don't think this will actually happen in all >cases with the current code. >Shouldn't you instead check for *any* signal in get_signaled_thread? Yes, kindly check the get_signaled_thread_rs6000 (). ---------------------------------------------------- These are the changes I made thinking about how we can handle that get_sign= aled thread in one place. I have also attached the outputs and programs bel= ow. Also, now we pass ptid in some functions instead of pid in aix-thread.c. Kindly let me know what you think. Have a nice day ahead. Thanks and regards, Aditya. ---------------------------------------------------------------------------= ------------------ BT:- Thread_wait Thread 1 hit Breakpoint 1, aix_thread_target::wait (this=3D0x11001f758 <_ai= xthread.rw_+24>, ptid=3D..., status=3D0xffffffffffff360, options=3D...) at aix-thread.c:1051 1051 pid_to_prc (&ptid); (gdb) bt #0 aix_thread_target::wait (this=3D0x11001f758 <_aixthread.rw_+24>, ptid= =3D..., status=3D0xffffffffffff360, options=3D...) at aix-thread.c:1051 #1 0x0000000100340778 in target_wait (ptid=3D..., status=3D0xffffffffffff3= 60, options=3D...) at target.c:2598 #2 0x000000010037f158 in do_target_wait_1 (inf=3D0x1101713f0, ptid=3D..., = status=3D0xffffffffffff360, options=3D...) at infrun.c:3763 #3 0x000000010037f41c in ::operator()(inferior *) const= ( __closure=3D0xffffffffffff130, inf=3D0x1101713f0) at infrun.c:3822 #4 0x000000010037f85c in do_target_wait (ecs=3D0xffffffffffff338, options= =3D...) at infrun.c:3841 #5 0x0000000100380cc8 in fetch_inferior_event () at infrun.c:4201 #6 0x0000000100a1e354 in inferior_event_handler (event_type=3DINF_REG_EVEN= T) at inf-loop.c:41 #7 0x0000000100392700 in infrun_async_inferior_event_handler (data=3D0x0) = at infrun.c:9555 #8 0x0000000100677d88 in check_async_event_handlers () at async-event.c:337 #9 0x000000010067439c in gdb_do_one_event (mstimeout=3D-1) at event-loop.c= c:221 #10 0x0000000100001dd0 in start_event_loop () at main.c:411 #11 0x0000000100001fd8 in captured_command_loop () at main.c:471 #12 0x0000000100004150 in captured_main (data=3D0xffffffffffff9f0) at main.= c:1330 #13 0x0000000100004224 in gdb_main (args=3D0xffffffffffff9f0) at main.c:1345 #14 0x0000000100000aa0 in main (argc=3D2, argv=3D0xffffffffffffa90) at gdb.= c:32 ------------------------------------------------------------ BT:- Post thread wait in rs6000-aix-nat::wait (gdb) c Continuing. Thread 1 hit Breakpoint 2, rs6000_nat_target::wait (this=3D0x1100a2e10 <_rs= 6000aixnat.rw_>, ptid=3D..., ourstatus=3D0xffffffffffff360, options=3D...) at rs6000-aix-nat.c:695 695 set_sigint_trap (); (gdb) bt #0 rs6000_nat_target::wait (this=3D0x1100a2e10 <_rs6000aixnat.rw_>, ptid= =3D..., ourstatus=3D0xffffffffffff360, options=3D...) at rs6000-aix-nat.c:695 #1 0x0000000100599d68 in aix_thread_target::wait (this=3D0x11001f758 <_aix= thread.rw_+24>, ptid=3D..., status=3D0xffffffffffff360, options=3D...) at aix-thread.c:1053 #2 0x0000000100340778 in target_wait (ptid=3D..., status=3D0xffffffffffff3= 60, options=3D...) at target.c:2598 #3 0x000000010037f158 in do_target_wait_1 (inf=3D0x1101713f0, ptid=3D..., = status=3D0xffffffffffff360, options=3D...) at infrun.c:3763 #4 0x000000010037f41c in ::operator()(inferior *) const= ( __closure=3D0xffffffffffff130, inf=3D0x1101713f0) at infrun.c:3822 #5 0x000000010037f85c in do_target_wait (ecs=3D0xffffffffffff338, options= =3D...) at infrun.c:3841 #6 0x0000000100380cc8 in fetch_inferior_event () at infrun.c:4201 #7 0x0000000100a1e354 in inferior_event_handler (event_type=3DINF_REG_EVEN= T) at inf-loop.c:41 #8 0x0000000100392700 in infrun_async_inferior_event_handler (data=3D0x0) = at infrun.c:9555 #9 0x0000000100677d88 in check_async_event_handlers () at async-event.c:337 #10 0x000000010067439c in gdb_do_one_event (mstimeout=3D-1) at event-loop.c= c:221 #11 0x0000000100001dd0 in start_event_loop () at main.c:411 #12 0x0000000100001fd8 in captured_command_loop () at main.c:471 #13 0x0000000100004150 in captured_main (data=3D0xffffffffffff9f0) at main.= c:1330 #14 0x0000000100004224 in gdb_main (args=3D0xffffffffffff9f0) at main.c:1345 #15 0x0000000100000aa0 in main (argc=3D2, argv=3D0xffffffffffffa90) at gdb.= c:32 ---------------------------------------------------------------------------= -------------------------- BT:- If direct rs6000-aix-nat::wait Thread 1 hit Breakpoint 2, rs6000_nat_target::wait (this=3D0x1100a2e10 <_rs= 6000aixnat.rw_>, ptid=3D..., ourstatus=3D0xffffffffffff360, options=3D...) at rs6000-aix-nat.c:695 695 set_sigint_trap (); (gdb) bt #0 rs6000_nat_target::wait (this=3D0x1100a2e10 <_rs6000aixnat.rw_>, ptid= =3D..., ourstatus=3D0xffffffffffff360, options=3D...) at rs6000-aix-nat.c:695 #1 0x0000000100340778 in target_wait (ptid=3D..., status=3D0xffffffffffff3= 60, options=3D...) at target.c:2598 #2 0x000000010037f158 in do_target_wait_1 (inf=3D0x1105f4430, ptid=3D..., = status=3D0xffffffffffff360, options=3D...) at infrun.c:3763 #3 0x000000010037f41c in ::operator()(inferior *) const= ( __closure=3D0xffffffffffff130, inf=3D0x1105f4430) at infrun.c:3822 #4 0x000000010037f85c in do_target_wait (ecs=3D0xffffffffffff338, options= =3D...) at infrun.c:3841 #5 0x0000000100380cc8 in fetch_inferior_event () at infrun.c:4201 #6 0x0000000100a1e354 in inferior_event_handler (event_type=3DINF_REG_EVEN= T) at inf-loop.c:41 #7 0x0000000100392700 in infrun_async_inferior_event_handler (data=3D0x0) = at infrun.c:9555 #8 0x0000000100677d88 in check_async_event_handlers () at async-event.c:337 #9 0x000000010067439c in gdb_do_one_event (mstimeout=3D-1) at event-loop.c= c:221 #10 0x0000000100001dd0 in start_event_loop () at main.c:411 #11 0x0000000100001fd8 in captured_command_loop () at main.c:471 #12 0x0000000100004150 in captured_main (data=3D0xffffffffffff9f0) at main.= c:1330 #13 0x0000000100004224 in gdb_main (args=3D0xffffffffffff9f0) at main.c:1345 #14 0x0000000100000aa0 in main (argc=3D2, argv=3D0xffffffffffffa90) at gdb.= c:32 --------------------------------------------------------- BT:- pid_to_str stack (gdb) bt #0 rs6000_nat_target::pid_to_str[abi:cxx11](ptid_t) (this=3D0x1100a2e10 <_= rs6000aixnat.rw_>, ptid=3D...) at rs6000-aix-nat.c:674 #1 0x00000001003409ec in target_pid_to_str[abi:cxx11](ptid_t) (ptid=3D...)= at target.c:2623 #2 0x000000010038fc08 in normal_stop () at infrun.c:8697 #3 0x0000000100380ff4 in fetch_inferior_event () at infrun.c:4266 #4 0x0000000100a1e354 in inferior_event_handler (event_type=3DINF_REG_EVEN= T) at inf-loop.c:41 #5 0x0000000100392700 in infrun_async_inferior_event_handler (data=3D0x0) = at infrun.c:9555 #6 0x0000000100677d88 in check_async_event_handlers () at async-event.c:337 #7 0x000000010067439c in gdb_do_one_event (mstimeout=3D-1) at event-loop.c= c:221 #8 0x0000000100001dd0 in start_event_loop () at main.c:411 #9 0x0000000100001fd8 in captured_command_loop () at main.c:471 #10 0x0000000100004150 in captured_main (data=3D0xffffffffffff9f0) at main.= c:1330 #11 0x0000000100004224 in gdb_main (args=3D0xffffffffffff9f0) at main.c:1345 #12 0x0000000100000aa0 in main (argc=3D2, argv=3D0xffffffffffffa90) at gdb.= c:32 --------------------------------------------------------------------- Program1:- [Credits gdb.threads/continuous-pending.c] #include #include #include #include #include pthread_barrier_t barrier; #define NUM_THREADS 3 void * thread_function (void *arg) { /* This ensures that the breakpoint is only hit after both threads are created, so the test can always switch to the non-event thread when the breakpoint triggers. */ pthread_barrier_wait (&barrier); while (1); /* break here */ } int main (void) { int i; alarm (300); pthread_barrier_init (&barrier, NULL, NUM_THREADS); for (i =3D 0; i < NUM_THREADS; i++) { pthread_t thread; int res; res =3D pthread_create (&thread, NULL, thread_function, NULL); assert (res =3D=3D 0); } while (1) sleep (1); return 0; } ---------------------------------------------------------------- Output1:- Single process Reading symbols from /home/aditya/gdb_tests/continue-pending-status... (gdb) r Starting program: /home/aditya/gdb_tests/continue-pending-status ^C[New Thread 258] [New Thread 515] [New Thread 772] Thread 3 received signal SIGINT, Interrupt. [Switching to Thread 515] thread_function (arg=3D0x0) at /home/aditya/gdb_tests/continue-pending-status.c:36 36 while (1); /* break here */ (gdb) info threads Id Target Id Frame 1 Thread 1 (tid 24838585, running) warning: (Internal error: pc 0x0 = in read in psymtab, but not in symtab.) 2 Thread 258 (tid 23134635, running) thread_function (arg=3Dwarning: (= Internal error: pc 0x0 in read in psymtab, but not in symtab.) 0x0) at /home/aditya/gdb_tests/continue-pending-status.c:36 * 3 Thread 515 (tid 30146867, running) thread_function (arg=3Dwarning: (= Internal error: pc 0x0 in read in psymtab, but not in symtab.) 0x0) at /home/aditya/gdb_tests/continue-pending-status.c:36 4 Thread 772 (tid 27853165, running) thread_function (arg=3Dwarning: (= Internal error: pc 0x0 in read in psymtab, but not in symtab.) 0x0) at /home/aditya/gdb_tests/continue-pending-status.c:36 ---------------------------------------------------------------------------= ------ Program 2:- Multi process Code #include #include #include #include #include pthread_barrier_t barrier; #define NUM_THREADS 2 void * thread_function (void *arg) { /* This ensures that the breakpoint is only hit after both threads are created, so the test can always switch to the non-event thread when the breakpoint triggers. */ pthread_barrier_wait (&barrier); pid_t child; child =3D fork (); if (child > 0) printf ("I am parent \n"); else{ printf (" Iam child \n"); child =3D fork (); if (child > 0) printf ("From child I became a parent \n"); else printf ("I am grandchild \n"); } while (1); /* break here */ } int main (void) { int i; alarm (300); pthread_barrier_init (&barrier, NULL, NUM_THREADS); for (i =3D 0; i < NUM_THREADS; i++) { pthread_t thread; int res; res =3D pthread_create (&thread, NULL, thread_function, NULL); assert (res =3D=3D 0); } while (1) { sleep (15); break; } return 0; } ------------------------------------------------------------------------- Output 2:- With detach-on-fork on Reading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork... (gdb) r Starting program: /home/aditya/gdb_tests/ultimate-multi-thread-fork [New Thread 258] [New Thread 515] [Detaching after fork from child process 8323572] Iam child I am grandchild =46rom child I became a parent I am parent [Detaching after fork from child process 11665884] Iam child I am grandchild =46rom child I became a parent I am parent ^C Thread 2 received signal SIGINT, Interrupt. [Switching to Thread 258] thread_function (arg=3D0x0) at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32 32 while (1); /* break here */ (gdb) info threads Id Target Id Frame 1 Thread 1 (tid 27263269, running) warning: (Internal error: pc 0x0 = in read in psymtab, but not in symtab.) * 2 Thread 258 (tid 28705075, running) thread_function (arg=3Dwarning: (= Internal error: pc 0x0 in read in psymtab, but not in symtab.) 0x0) at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32 3 Thread 515 (tid 27853169, running) thread_function (arg=3Dwarning: (= Internal error: pc 0x0 in read in psymtab, but not in symtab.) 0x0) at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32 ------------------------------------------------------------------------- Output 3:- With detach-on-fork off Reading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork... (gdb) set detach-on-fork off (gdb) r Starting program: /home/aditya/gdb_tests/ultimate-multi-thread-fork [New Thread 258] [New Thread 515] [New inferior 2 (Process 15466928)] [New inferior 3 (Process 13894048)] I am parent I am parent ^C Thread 1.1 received signal SIGINT, Interrupt. [Switching to Thread 1] 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) (gdb) info threads Id Target Id Frame * 1.1 Thread 1 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) 1.2 Thread 258 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) 1.3 Thread 515 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) 2.1 Process 15466928 0xd0594fc8 in ?? () 3.1 Process 13894048 0xd0594fc8 in ?? () -------------------------------------------------- Output 4:- detach fork off and following child Reading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork... (gdb) set detach-on-fork off (gdb) set follow-fork-mode child (gdb) r Starting program: /home/aditya/gdb_tests/ultimate-multi-thread-fork [New Thread 258] [New Thread 515] [Attaching after Thread 515 fork to child Process 13894050] [New inferior 2 (Process 13894050)] Iam child [Attaching after Process 13894050 fork to child Process 11010474] [New inferior 3 (Process 11010474)] I am grandchild ^CReading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork... Thread 3.1 received signal SIGINT, Interrupt. [Switching to Process 11010474] thread_function (arg=3D0x0) at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32 32 while (1); /* break here */ (gdb) info threads Id Target Id Frame 1.1 Thread 1 0xd0594fc8 in _sigsetmask () from /usr/lib/libpthread.a(shr_xpg5.o) 1.2 Thread 258 0xd0594fc8 in _sigsetmask () from /usr/lib/libpthread.a(shr_xpg5.o) 1.3 Thread 515 0xd0594fc8 in _sigsetmask () from /usr/lib/libpthread.a(shr_xpg5.o) 2.1 Process 13894050 0xd0594fc8 in ?? () * 3.1 Process 11010474 thread_function (arg=3Dwarning: (Internal error: p= c 0x0 in read in psymtab, but not in symtab.) 0x0) at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32 ________________________________ From: Ulrich Weigand Sent: 06 December 2022 00:03 To: simark@simark.ca ; Aditya Kamath1 ; gdb-patches@sourceware.org Cc: Sangamesh Mallayya Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch Aditya Kamath1 wrote: >>I'm not sure why it is necessary to handle this in the process layer >>(rs6000-aix-nat.c) instead of the thread layer (aix-thread.c). >>What specifically breaks if you do not have these rs6000-aix-nat.c >>changes? > >So, if you observe output 3 or 4, the program first multi threads, >I mean thread events are handled first and then the threads fork. >So, when this happens, I cannot return ptid_t (parent_pid). If I do >so, the GDB core will treat it as a new process and add it in my >threadlist as say process 100 despite existence of 'thread 1' >representing the same. So, I need to correctly send which thread >did the fork () event or which thread of the process is the one who >gave birth to a new inferior process [say 2 or 3 in output 3 below], >I mean which thread caused the mult process event when the process >is mutli threaded. This has to handled here as control from target.c >comes directly to rs6000-aix-nat::wait and not through >aix-thread.c::wait since fork () is a process event.. So this last bit seems to be the problem. Could you elaborate on what the exact call stack is? I thought once the thread layer is initialized, calls to ::wait should always go through it ... >>If you *do* need to handle LWPs (kernel thread IDs) in the process >>layer (this can be a reasonable choice, and it done by several other >>native targets), then it should be *consistent*, and *all* LWP handling >>should be in the process layer. In particular, under no circumstances >>does it make sense to duplicate the "find current/signalled thread" >>code in *both* the process any thread layers. > >This not straightforward to do. The reason being say our application is pt= hreaded >We need our sync_threadlists() code to detect multiple threads and sync.. >We cannot handle this in rs6000-aix-nat.c with the current design of the c= ode.. >Let's say child process is multi-threaded things can get complex.. >It will require us to move that whole GDB list and Pthread list sync code = to >rs6000-aix-nat.c code. The essence or most selling product or the USP >[Unique Selling Proposition] of aix-thread.c code will be lost. So the way this works e.g. on Linux is that the process layer handles both processes and the *kernel* aspect of threads, while the thread layer handles the *user-space* (libc/libpthread) aspect of threads. In terms of the GDB ptid_t, this means that both the "pid" and "lwp" field are "owned" by the process layer (which would be rs6000-aix-nat.c in your case), while only the "tid" field is owned by the thread layer (which would be aix-thread.c). Linux does that because it allows correctly debugging programs that only use the kernel threading capabilities without using libpthread, e.g. by directly calling the "clone" system call and not "pthread_create". Such threads won't be in the thread list managed by the user space library, but are still handled by the process layer in GDB, tracked as lwp without associated tid. Not sure if something like that is even possible in AIX. If it does make sense to handle things similarly in AIX (one other reason would be ptrace commands that require LWPs, e.g. like the VSX register access you had in another thread), some code would indeed need to move, e.g. everything related to accessing *kernel* threads (fetch_regs_kernel_thread etc.), while code that accesses *user* threads via the libpthread accessors (fetch_regs_user_thread etc.) would still remain in aix-thread.c. >>>[Switching to process 16777620] > >>This outputs inferior_ptid ... > >Yes, you were right > >>>* 1.1 process 16777620 0xd0595fb0 in _p_nsleep () >>> from /usr/lib/libpthread.a(shr_xpg5.o) >>> 1.2 process 16777620 0xd0595fb0 in _p_nsleep () >>> from /usr/lib/libpthread.a(shr_xpg5.o) >>> 1.3 process 16777620 0xd0595fb0 in _p_nsleep () >>> from /usr/lib/libpthread.a(shr_xpg5.o) >>> 2.1 process 8323570 0xd0594fc8 in ?? () >>> 3.1 process 17957172 0xd0594fc8 in ?? () > >>... and this outputs the ptid values for those threads. > >>If it says "process ...", then those ptid values have not >>properly been switched over to the (pid, lwp, tid) format. >While debugged in depth last two days I realised our pid_to_str >is needed in rs6000-aix-nat.c as control comes here in search of it. >If it doesn't GDB treats all threads as process. This is again very suspicious. We obviously already have threads, so the thread layer should be initialized. This means that any "pid_to_str" call should go through the *thread* layer (implementation in aix-thread.c). If that doesn't happen, we should understand why. (This may be the same problem that causes "wait" to be called from the wrong layer, as seen above.) >>You should verify that the sync_threadlists code handles >>all multi-process cases correctly. I haven't looked at >>this in detail, but are you sure that here: > >>>@@ -841,8 +829,22 @@ sync_threadlists (int pid) > >> } > >> else if (cmp_result > 0) > >> { >>>- delete_thread (gbuf[gi]); > > >>you never accidentally switch the *pid* part (if "gptid" >>belows to a different pid than "pptid")? > >So, this is not the reason. I have added an assertion here just >to be sure. I get what you are thinking. Having an assertion is of course good, but it isn't obvious to me that this never can be hit. >>Hmm. So when "wait" returns, it needs to determine which thread >>triggered the event that caused ptrace to stop. On Linux, "wait" >>will actually return the LWP of that thread, so it can be directly >>used. It seems on AIX, "wait" only returns a PID, and you do not >>immediately know which thread caused the event? > >>In that case, I can see why you'd have to consider SIGINT as well >>as SIGTRAP. However, it seems to me that even those two are not the >>*only* cases that can cause "wait" to return - doesn't *any* signal >>(potentially) trigger a ptrace intercept (causing wait to return)? > >>But that's probably a more general problem, and wouldn't occur in >>this simple test case. > >Exactly. So I tried debugging few examples causing a few other signals >as mentioned in this document [https://www.ibm.com/docs/en/sdk-java-techno= logy/8?topic=3Dreference-signal-handling]. >In AIX we have most of them mentioned in the link. It does not block >us from doing things or crashes incase of a segment fault signal >[from our debugger code]. Abort also works fine. Let me know what you thin= k. The point is if GDB stops because the target received a signal, it should automatically switch to the particular thread where the signal was in fact received. I don't think this will actually happen in all cases with the current code. Shouldn't you instead check for *any* signal in get_signaled_thread? Bye, Ulrich --_000_CH2PR15MB35447EE88C64F7F36A0C61F5D61D9CH2PR15MB3544namp_-- --_004_CH2PR15MB35447EE88C64F7F36A0C61F5D61D9CH2PR15MB3544namp_ Content-Type: application/octet-stream; name="0001-Fix-multi-thread-bug-in-AIX.patch" Content-Description: 0001-Fix-multi-thread-bug-in-AIX.patch Content-Disposition: attachment; filename="0001-Fix-multi-thread-bug-in-AIX.patch"; size=12381; creation-date="Thu, 08 Dec 2022 10:25:27 GMT"; modification-date="Thu, 08 Dec 2022 10:25:34 GMT" Content-Transfer-Encoding: base64 RnJvbSBiYmE5MWY3MTdiNzc3OWYzOWQ3MTI4MjgzNWNjZWFhZWRhN2VmNTg4 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBBZGl0eWEgVmlkeWFk aGFyIEthbWF0aCA8QWRpdHlhLkthbWF0aDFAaWJtLmNvbT4KRGF0ZTogVGh1 LCA4IERlYyAyMDIyIDAxOjAzOjU4IC0wNjAwClN1YmplY3Q6IFtQQVRDSF0g Rml4IG11bHRpIHRocmVhZCBidWcgaW4gQUlYCgotLS0KIGdkYi9haXgtdGhy ZWFkLmMgICAgIHwgMTQ5ICsrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KIGdkYi9yczYwMDAtYWl4LW5hdC5jIHwgIDY2ICsr KysrKysrKysrKysrKysrKy0KIDIgZmlsZXMgY2hhbmdlZCwgMTE4IGluc2Vy dGlvbnMoKyksIDk3IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2dkYi9h aXgtdGhyZWFkLmMgYi9nZGIvYWl4LXRocmVhZC5jCmluZGV4IGU1NTZjMTUz NTc2Li42ZTZmODYxOWI2NCAxMDA2NDQKLS0tIGEvZ2RiL2FpeC10aHJlYWQu YworKysgYi9nZGIvYWl4LXRocmVhZC5jCkBAIC01MDgsMTQgKzUwOCwxMyBA QCBwZGNfcmVhZF9kYXRhIChwdGhkYl91c2VyX3QgdXNlcl9jdXJyZW50X3Bp ZCwgdm9pZCAqYnVmLAogICAvKiBUaGlzIGlzIG5lZWRlZCB0byBlbGltaW5h dGUgdGhlIGRlcGVuZGVuY3kgb2YgY3VycmVudCB0aHJlYWQKICAgICAgd2hp Y2ggaXMgbnVsbCBzbyB0aGF0IHRocmVhZCByZWFkcyB0aGUgY29ycmVjdCB0 YXJnZXQgbWVtb3J5LiAgKi8KICAgewotICAgIHNjb3BlZF9yZXN0b3JlX2N1 cnJlbnRfdGhyZWFkIHJlc3RvcmVfY3VycmVudF90aHJlYWQ7CisgICAgc2Nv cGVkX3Jlc3RvcmUgc2F2ZV9pbmZlcmlvcl9wdGlkID0gbWFrZV9zY29wZWRf cmVzdG9yZSAoJmluZmVyaW9yX3B0aWQpOwogICAgIC8qIEJlZm9yZSB0aGUg Zmlyc3QgaW5mZXJpb3IgaXMgYWRkZWQsIHdlIHBhc3MgaW5mZXJpb3JfcHRp ZC5waWQgKCkKICAgICAgICBmcm9tIHBkX2VuYWJsZSAoKSB3aGljaCBpcyAw LiAgVGhlcmUgaXMgbm8gbmVlZCB0byBzd2l0Y2ggdGhyZWFkcwogICAgICAg IGR1cmluZyBmaXJzdCBpbml0aWFsaXNhdGlvbi4gIEluIHRoZSByZXN0IG9m IHRoZSBjYWxsYmFja3MgdGhlCiAgICAgICAgY3VycmVudCB0aHJlYWQgbmVl ZHMgdG8gYmUgY29ycmVjdC4gICovCiAgICAgaWYgKHVzZXJfY3VycmVudF9w aWQgIT0gMCkKLSAgICAgIHN3aXRjaF90b190aHJlYWQgKGN1cnJlbnRfaW5m ZXJpb3IgKCktPnByb2Nlc3NfdGFyZ2V0ICgpLAotCQkJcHRpZF90ICh1c2Vy X2N1cnJlbnRfcGlkKSk7CisgICAgICBpbmZlcmlvcl9wdGlkID0gcHRpZF90 ICh1c2VyX2N1cnJlbnRfcGlkKTsKICAgICBzdGF0dXMgPSB0YXJnZXRfcmVh ZF9tZW1vcnkgKGFkZHIsIChnZGJfYnl0ZSAqKSBidWYsIGxlbik7CiAgIH0K ICAgcmV0ID0gc3RhdHVzID09IDAgPyBQRENfU1VDQ0VTUyA6IFBEQ19GQUlM VVJFOwpAQCAtNjM5LDM2ICs2MzgsMjQgQEAgcGNtcCAoY29uc3Qgdm9pZCAq cDF2LCBjb25zdCB2b2lkICpwMnYpCiAgIHJldHVybiBwMS0+cHRoaWQgPCBw Mi0+cHRoaWQgPyAtMSA6IHAxLT5wdGhpZCA+IHAyLT5wdGhpZDsKIH0KIAot LyogaXRlcmF0ZV9vdmVyX3RocmVhZHMoKSBjYWxsYmFjayBmb3IgY291bnRp bmcgR0RCIHRocmVhZHMuCisvKiBpdGVyYXRlX292ZXJfdGhyZWFkcygpIGNh bGxiYWNrIGZvciBjb3VudGluZyBHREIgdGhyZWFkcy4gICovCiAKLSAgIERv IG5vdCBjb3VudCB0aGUgbWFpbiB0aHJlYWQgKHdob3NlIHRpZCBpcyB6ZXJv KS4gIFRoaXMgbWF0Y2hlcwotICAgdGhlIGxpc3Qgb2YgdGhyZWFkcyBwcm92 aWRlZCBieSB0aGUgcHRocmVhZGRlYnVnIGxpYnJhcnksIHdoaWNoCi0gICBk b2VzIG5vdCBpbmNsdWRlIHRoYXQgbWFpbiB0aHJlYWQgZWl0aGVyLCBhbmQg dGh1cyBhbGxvd3MgdXMKLSAgIHRvIGNvbXBhcmUgdGhlIHR3byBsaXN0cy4g ICovCiAKIHN0YXRpYyBpbnQKIGdpdGVyX2NvdW50IChzdHJ1Y3QgdGhyZWFk X2luZm8gKnRocmVhZCwgdm9pZCAqY291bnRwKQogewotICBpZiAoUERfVElE ICh0aHJlYWQtPnB0aWQpKQotICAgICgqKGludCAqKSBjb3VudHApKys7Cisg ICgqKGludCAqKSBjb3VudHApKys7CiAgIHJldHVybiAwOwogfQogCi0vKiBp dGVyYXRlX292ZXJfdGhyZWFkcygpIGNhbGxiYWNrIGZvciBhY2N1bXVsYXRp bmcgR0RCIHRocmVhZCBwaWRzLgotCi0gICBEbyBub3QgaW5jbHVkZSB0aGUg bWFpbiB0aHJlYWQgKHdob3NlIHRpZCBpcyB6ZXJvKS4gIFRoaXMgbWF0Y2hl cwotICAgdGhlIGxpc3Qgb2YgdGhyZWFkcyBwcm92aWRlZCBieSB0aGUgcHRo cmVhZGRlYnVnIGxpYnJhcnksIHdoaWNoCi0gICBkb2VzIG5vdCBpbmNsdWRl IHRoYXQgbWFpbiB0aHJlYWQgZWl0aGVyLCBhbmQgdGh1cyBhbGxvd3MgdXMK LSAgIHRvIGNvbXBhcmUgdGhlIHR3byBsaXN0cy4gICovCisvKiBpdGVyYXRl X292ZXJfdGhyZWFkcygpIGNhbGxiYWNrIGZvciBhY2N1bXVsYXRpbmcgR0RC IHRocmVhZCBwaWRzLiAgKi8KIAogc3RhdGljIGludAogZ2l0ZXJfYWNjdW0g KHN0cnVjdCB0aHJlYWRfaW5mbyAqdGhyZWFkLCB2b2lkICpidWZwKQogewot ICBpZiAoUERfVElEICh0aHJlYWQtPnB0aWQpKQotICAgIHsKLSAgICAgICoq KHN0cnVjdCB0aHJlYWRfaW5mbyAqKiopIGJ1ZnAgPSB0aHJlYWQ7Ci0gICAg ICAoKihzdHJ1Y3QgdGhyZWFkX2luZm8gKioqKSBidWZwKSsrOwotICAgIH0K KyAgKiooc3RydWN0IHRocmVhZF9pbmZvICoqKikgYnVmcCA9IHRocmVhZDsK KyAgKCooc3RydWN0IHRocmVhZF9pbmZvICoqKikgYnVmcCkrKzsKKyAgICAK ICAgcmV0dXJuIDA7CiB9CiAKQEAgLTcwMywzMCArNjkwLDYgQEAgZ2NtcCAo Y29uc3Qgdm9pZCAqdDF2LCBjb25zdCB2b2lkICp0MnYpCiAgIHJldHVybiBw dGlkX2NtcCAodDEtPnB0aWQsIHQyLT5wdGlkKTsKIH0KIAotLyogU2VhcmNo IHRocm91Z2ggdGhlIGxpc3Qgb2YgYWxsIGtlcm5lbCB0aHJlYWRzIGZvciB0 aGUgdGhyZWFkCi0gICB0aGF0IGhhcyBzdG9wcGVkIG9uIGEgU0lHVFJBUCBz aWduYWwsIGFuZCByZXR1cm4gaXRzIFRJRC4KLSAgIFJldHVybiAwIGlmIG5v bmUgZm91bmQuICAqLwotCi1zdGF0aWMgcHRoZGJfdGlkX3QKLWdldF9zaWdu YWxlZF90aHJlYWQgKGludCBwaWQpCi17Ci0gIHN0cnVjdCB0aHJkc2luZm82 NCB0aHJpbmY7Ci0gIHRpZF90IGt0aWQgPSAwOwotCi0gIHdoaWxlICgxKQot ICAgIHsKLSAgICAgIGlmIChnZXR0aHJkcyAocGlkLCAmdGhyaW5mLAotCQkg ICAgc2l6ZW9mICh0aHJpbmYpLCAma3RpZCwgMSkgIT0gMSkKLQlicmVhazsK LQotICAgICAgaWYgKHRocmluZi50aV9jdXJzaWcgPT0gU0lHVFJBUCkKLQly ZXR1cm4gdGhyaW5mLnRpX3RpZDsKLSAgICB9Ci0KLSAgLyogRGlkbid0IGZp bmQgYW55IHRocmVhZCBzdG9wcGVkIG9uIGEgU0lHVFJBUCBzaWduYWwuICAq LwotICByZXR1cm4gMDsKLX0KLQogLyogU3luY2hyb25pemUgR0RCJ3MgdGhy ZWFkIGxpc3Qgd2l0aCBsaWJwdGhkZWJ1ZydzLgogCiAgICBUaGVyZSBhcmUg c29tZSBiZW5lZml0cyBvZiBkb2luZyB0aGlzIGV2ZXJ5IHRpbWUgdGhlIGlu ZmVyaW9yIHN0b3BzOgpAQCAtNzQwLDggKzcwMyw4IEBAIGdldF9zaWduYWxl ZF90aHJlYWQgKGludCBwaWQpCiAgICAgIC0gc2ltcGxpZmllcyB0aGUgZGVt YW5kcyBwbGFjZWQgb24gbGlicHRoZGVidWcsIHdoaWNoIHNlZW1zIHRvCiAg ICAgICAgaGF2ZSBkaWZmaWN1bHR5IHdpdGggY2VydGFpbiBjYWxsIHBhdHRl cm5zICovCiAKLXN0YXRpYyB2b2lkCi1zeW5jX3RocmVhZGxpc3RzIChpbnQg cGlkKQorc3RhdGljIHB0aWRfdCAKK3N5bmNfdGhyZWFkbGlzdHMgKHB0aWRf dCBwdGlkKQogewogICBpbnQgY21kLCBzdGF0dXM7CiAgIGludCBwY291bnQs IHBzaXplLCBwaSwgZ2NvdW50LCBnaTsKQEAgLTc1MCw2ICs3MTMsMTUgQEAg c3luY190aHJlYWRsaXN0cyAoaW50IHBpZCkKICAgcHRoZGJfcHRocmVhZF90 IHBkdGlkOwogICBwdGhyZWFkX3QgcHRoaWQ7CiAgIHB0aGRiX3RpZF90IHRp ZDsKKyAgcHJvY2Vzc19zdHJhdHVtX3RhcmdldCAqcHJvY190YXJnZXQKKwk9 IGN1cnJlbnRfaW5mZXJpb3IgKCktPnByb2Nlc3NfdGFyZ2V0ICgpOworICB0 aHJlYWRfaW5mbyAqdHA7CisgIHBpZF90IHBpZCA9IHB0aWQucGlkICgpOwor CisgIC8qIFRoaXMgcHRpZCBzaG91bGQgaG9sZCB0aGUgcHRpZCBvZiBhIG5l dyB0aHJlYWQgCisgICAgIG9yIHJldHVybiB0aGUgaW5jb21pbmcgcHRpZCBp bmNhc2Ugb2YgZGVsZXRlIHRocmVhZC4gICovCisKKyAgcHRpZF90IHBvc3Rf c3luY19wdGlkID0gcHRpZDsKIAogICAvKiBBY2N1bXVsYXRlIGFuIGFycmF5 IG9mIGxpYnB0aGRlYnVnIHRocmVhZHMgc29ydGVkIGJ5IHB0aHJlYWQgaWQu ICAqLwogCkBAIC04MTAsMTIgKzc4MiwxMCBAQCBzeW5jX3RocmVhZGxpc3Rz IChpbnQgcGlkKQogCSAgcHJpdi0+cGR0aWQgPSBwYnVmW3BpXS5wZHRpZDsK IAkgIHByaXYtPnRpZCA9IHBidWZbcGldLnRpZDsKIAotCSAgcHJvY2Vzc19z dHJhdHVtX3RhcmdldCAqcHJvY190YXJnZXQKLQkgICAgPSBjdXJyZW50X2lu ZmVyaW9yICgpLT5wcm9jZXNzX3RhcmdldCAoKTsKIAkgIHRocmVhZCA9IGFk ZF90aHJlYWRfd2l0aF9pbmZvIChwcm9jX3RhcmdldCwKLQkJCQkJIHB0aWRf dCAocGlkLCAwLCBwYnVmW3BpXS5wdGhpZCksCisJCQkJCSBwdGlkX3QgKHBp ZCwgcGJ1ZltwaV0udGlkLCBwYnVmW3BpXS5wdGhpZCksCiAJCQkJCSBwcml2 KTsKLQorCSAgcG9zdF9zeW5jX3B0aWQgPSB0aHJlYWQtPnB0aWQ7CiAJICBw aSsrOwogCX0KICAgICAgIGVsc2UKQEAgLTgyMyw3ICs3OTMsNyBAQCBzeW5j X3RocmVhZGxpc3RzIChpbnQgcGlkKQogCSAgcHRpZF90IHBwdGlkLCBncHRp ZDsKIAkgIGludCBjbXBfcmVzdWx0OwogCi0JICBwcHRpZCA9IHB0aWRfdCAo cGlkLCAwLCBwYnVmW3BpXS5wdGhpZCk7CisJICBwcHRpZCA9IHB0aWRfdCAo cGlkLCBwYnVmW3BpXS50aWQsIHBidWZbcGldLnB0aGlkKTsKIAkgIGdwdGlk ID0gZ2J1ZltnaV0tPnB0aWQ7CiAJICBwZHRpZCA9IHBidWZbcGldLnBkdGlk OwogCSAgdGlkID0gcGJ1ZltwaV0udGlkOwpAQCAtODQxLDE1ICs4MTEsMzEg QEAgc3luY190aHJlYWRsaXN0cyAoaW50IHBpZCkKIAkgICAgfQogCSAgZWxz ZSBpZiAoY21wX3Jlc3VsdCA+IDApCiAJICAgIHsKLQkgICAgICBkZWxldGVf dGhyZWFkIChnYnVmW2dpXSk7Ci0JICAgICAgZ2krKzsKKwkgICAgICBpZiAo Z3B0aWQuaXNfcGlkICgpKQorCQl7CisJCSAgZ2RiX2Fzc2VydCAoZ3B0aWQu cGlkICgpID09IHBwdGlkLnBpZCAoKSk7CisJCSAgdGhyZWFkX2NoYW5nZV9w dGlkIChwcm9jX3RhcmdldCwgZ3B0aWQsIHBwdGlkKTsKKwkJICBhaXhfdGhy ZWFkX2luZm8gKnByaXYgPSBuZXcgYWl4X3RocmVhZF9pbmZvOworCQkgIHBy aXYtPnBkdGlkID0gcGJ1ZltwaV0ucGR0aWQ7CisJCSAgcHJpdi0+dGlkID0g cGJ1ZltwaV0udGlkOworCQkgIHRwID0gZmluZF90aHJlYWRfcHRpZCAocHJv Y190YXJnZXQsIHBwdGlkKTsKKwkJICB0cC0+cHJpdi5yZXNldCAocHJpdik7 CisJCSAgcGkrKzsKKwkJICBnaSsrOworCQkgIHBvc3Rfc3luY19wdGlkID0g cHB0aWQ7CisJCX0KKwkgICAgICBlbHNlCisJCXsKKwkJICBkZWxldGVfdGhy ZWFkIChnYnVmW2dpXSk7CisJCSAgZ2krKzsKKwkJfQogCSAgICB9CiAJICBl bHNlCiAJICAgIHsKIAkgICAgICBwcm9jZXNzX3N0cmF0dW1fdGFyZ2V0ICpw cm9jX3RhcmdldAogCQk9IGN1cnJlbnRfaW5mZXJpb3IgKCktPnByb2Nlc3Nf dGFyZ2V0ICgpOwogCSAgICAgIHRocmVhZCA9IGFkZF90aHJlYWQgKHByb2Nf dGFyZ2V0LCBwcHRpZCk7Ci0KKwkgICAgICBwb3N0X3N5bmNfcHRpZCA9IHBw dGlkOwkKIAkgICAgICBhaXhfdGhyZWFkX2luZm8gKnByaXYgPSBuZXcgYWl4 X3RocmVhZF9pbmZvOwogCSAgICAgIHRocmVhZC0+cHJpdi5yZXNldCAocHJp dik7CiAJICAgICAgcHJpdi0+cGR0aWQgPSBwZHRpZDsKQEAgLTg2MSwxOCAr ODQ3LDcgQEAgc3luY190aHJlYWRsaXN0cyAoaW50IHBpZCkKIAogICB4ZnJl ZSAocGJ1Zik7CiAgIHhmcmVlIChnYnVmKTsKLX0KLQotLyogSXRlcmF0ZV9v dmVyX3RocmVhZHMoKSBjYWxsYmFjayBmb3IgbG9jYXRpbmcgYSB0aHJlYWQs IHVzaW5nCi0gICB0aGUgVElEIG9mIGl0cyBhc3NvY2lhdGVkIGtlcm5lbCB0 aHJlYWQuICAqLwotCi1zdGF0aWMgaW50Ci1pdGVyX3RpZCAoc3RydWN0IHRo cmVhZF9pbmZvICp0aHJlYWQsIHZvaWQgKnRpZHApCi17Ci0gIGNvbnN0IHB0 aGRiX3RpZF90IHRpZCA9ICoocHRoZGJfdGlkX3QgKil0aWRwOwotICBhaXhf dGhyZWFkX2luZm8gKnByaXYgPSBnZXRfYWl4X3RocmVhZF9pbmZvICh0aHJl YWQpOwotCi0gIHJldHVybiBwcml2LT50aWQgPT0gdGlkOworICByZXR1cm4g cG9zdF9zeW5jX3B0aWQ7CiB9CiAKIC8qIFN5bmNocm9uaXplIGxpYnB0aGRl YnVnJ3Mgc3RhdGUgd2l0aCB0aGUgaW5mZXJpb3IgYW5kIHdpdGggR0RCLApA QCAtODgxLDMzICs4NTYsMjMgQEAgaXRlcl90aWQgKHN0cnVjdCB0aHJlYWRf aW5mbyAqdGhyZWFkLCB2b2lkICp0aWRwKQogICAgcmV0dXJuIGEgcGlkLW9u bHkgcHRpZCB3aXRoIFBJRC4gICovCiAKIHN0YXRpYyBwdGlkX3QKLXBkX3Vw ZGF0ZSAoaW50IHBpZCkKK3BkX3VwZGF0ZSAocHRpZF90IHB0aWQpCiB7CiAg IGludCBzdGF0dXM7Ci0gIHB0aWRfdCBwdGlkOwogICBwdGhkYl90aWRfdCB0 aWQ7CiAgIHN0cnVjdCB0aHJlYWRfaW5mbyAqdGhyZWFkID0gTlVMTDsKKyAg cHRpZF90IHBvc3Rfc3luY19wdGlkOwogCiAgIGlmICghcGRfYWN0aXZlKQot ICAgIHJldHVybiBwdGlkX3QgKHBpZCk7CisgICAgcmV0dXJuIHB0aWQ7CiAK ICAgc3RhdHVzID0gcHRoZGJfc2Vzc2lvbl91cGRhdGUgKHBkX3Nlc3Npb24p OwogICBpZiAoc3RhdHVzICE9IFBUSERCX1NVQ0NFU1MpCi0gICAgcmV0dXJu IHB0aWRfdCAocGlkKTsKKyAgICByZXR1cm4gcHRpZDsKIAotICBzeW5jX3Ro cmVhZGxpc3RzIChwaWQpOworICBwb3N0X3N5bmNfcHRpZCA9IHN5bmNfdGhy ZWFkbGlzdHMgKHB0aWQpOwogCi0gIC8qIERlZmluZSAiY3VycmVudCB0aHJl YWQiIGFzIG9uZSB0aGF0IGp1c3QgcmVjZWl2ZWQgYSB0cmFwIHNpZ25hbC4g ICovCi0KLSAgdGlkID0gZ2V0X3NpZ25hbGVkX3RocmVhZCAocGlkKTsKLSAg aWYgKHRpZCAhPSAwKQotICAgIHRocmVhZCA9IGl0ZXJhdGVfb3Zlcl90aHJl YWRzIChpdGVyX3RpZCwgJnRpZCk7Ci0gIGlmICghdGhyZWFkKQotICAgIHB0 aWQgPSBwdGlkX3QgKHBpZCk7Ci0gIGVsc2UKLSAgICBwdGlkID0gdGhyZWFk LT5wdGlkOwotCi0gIHJldHVybiBwdGlkOworICByZXR1cm4gcG9zdF9zeW5j X3B0aWQ7CiB9CiAKIC8qIFRyeSB0byBzdGFydCBkZWJ1Z2dpbmcgdGhyZWFk cyBpbiB0aGUgY3VycmVudCBwcm9jZXNzLgpAQCAtOTE1LDE5ICs4ODAsMTkg QEAgcGRfdXBkYXRlIChpbnQgcGlkKQogICAgZm9yIHRoYXQgdGhyZWFkLiAg T3RoZXJ3aXNlLCByZXR1cm4gYSBwdGlkLW9ubHkgcHRpZCB1c2luZyBQSUQu ICAqLwogCiBzdGF0aWMgcHRpZF90Ci1wZF9hY3RpdmF0ZSAoaW50IHBpZCkK K3BkX2FjdGl2YXRlIChwdGlkX3QgcHRpZCkKIHsKICAgaW50IHN0YXR1czsK IAkJCi0gIHN0YXR1cyA9IHB0aGRiX3Nlc3Npb25faW5pdCAocGlkLCBhcmNo NjQgPyBQRU1fNjRCSVQgOiBQRU1fMzJCSVQsCisgIHN0YXR1cyA9IHB0aGRi X3Nlc3Npb25faW5pdCAocHRpZC5waWQgKCksIGFyY2g2NCA/IFBFTV82NEJJ VCA6IFBFTV8zMkJJVCwKIAkJCSAgICAgICBQVEhEQl9GTEFHX1JFR1MsICZw ZF9jYWxsYmFja3MsIAogCQkJICAgICAgICZwZF9zZXNzaW9uKTsKICAgaWYg KHN0YXR1cyAhPSBQVEhEQl9TVUNDRVNTKQogICAgIHsKLSAgICAgIHJldHVy biBwdGlkX3QgKHBpZCk7CisgICAgICByZXR1cm4gcHRpZDsKICAgICB9CiAg IHBkX2FjdGl2ZSA9IDE7Ci0gIHJldHVybiBwZF91cGRhdGUgKHBpZCk7Cisg IHJldHVybiBwZF91cGRhdGUgKHB0aWQpOwogfQogCiAvKiBVbmRvIHRoZSBl ZmZlY3RzIG9mIHBkX2FjdGl2YXRlKCkuICAqLwpAQCAtOTgzLDcgKzk0OCw3 IEBAIHBkX2VuYWJsZSAodm9pZCkKICAgLyogSWYgd2UncmUgZGVidWdnaW5n IGEgY29yZSBmaWxlIG9yIGFuIGF0dGFjaGVkIGluZmVyaW9yLCB0aGUKICAg ICAgcHRocmVhZCBsaWJyYXJ5IG1heSBhbHJlYWR5IGhhdmUgYmVlbiBpbml0 aWFsaXplZCwgc28gdHJ5IHRvCiAgICAgIGFjdGl2YXRlIHRocmVhZCBkZWJ1 Z2dpbmcuICAqLwotICBwZF9hY3RpdmF0ZSAoaW5mZXJpb3JfcHRpZC5waWQg KCkpOworICBwZF9hY3RpdmF0ZSAoaW5mZXJpb3JfcHRpZCk7CiB9CiAKIC8q IFVuZG8gdGhlIGVmZmVjdHMgb2YgcGRfZW5hYmxlKCkuICAqLwpAQCAtMTA5 MSwxMCArMTA1Niw2IEBAIGFpeF90aHJlYWRfdGFyZ2V0Ojp3YWl0IChwdGlk X3QgcHRpZCwgc3RydWN0IHRhcmdldF93YWl0c3RhdHVzICpzdGF0dXMsCiAg IGlmIChwdGlkLnBpZCAoKSA9PSAtMSkKICAgICByZXR1cm4gcHRpZF90ICgt MSk7CiAKLSAgLyogVGhlIHRhcmdldCBiZW5lYXRoIGRvZXMgbm90IGRlYWwg d2l0aCB0aHJlYWRzLCBzbyBpdCBzaG91bGQgb25seSByZXR1cm4KLSAgICAg cGlkLW9ubHkgcHRpZHMuICAqLwotICBnZGJfYXNzZXJ0IChwdGlkLmlzX3Bp ZCAoKSk7Ci0KICAgLyogQ2hlY2sgd2hldGhlciBsaWJwdGhkZWJ1ZyBtaWdo dCBiZSByZWFkeSB0byBiZSBpbml0aWFsaXplZC4gICovCiAgIGlmICghcGRf YWN0aXZlICYmIHN0YXR1cy0+a2luZCAoKSA9PSBUQVJHRVRfV0FJVEtJTkRf U1RPUFBFRAogICAgICAgJiYgc3RhdHVzLT5zaWcgKCkgPT0gR0RCX1NJR05B TF9UUkFQKQpAQCAtMTEwNiwxMCArMTA2NywxMCBAQCBhaXhfdGhyZWFkX3Rh cmdldDo6d2FpdCAocHRpZF90IHB0aWQsIHN0cnVjdCB0YXJnZXRfd2FpdHN0 YXR1cyAqc3RhdHVzLAogCiAgICAgICBpZiAocmVnY2FjaGVfcmVhZF9wYyAo cmVnY2FjaGUpCiAJICAtIGdkYmFyY2hfZGVjcl9wY19hZnRlcl9icmVhayAo Z2RiYXJjaCkgPT0gcGRfYnJrX2FkZHIpCi0JcmV0dXJuIHBkX2FjdGl2YXRl IChwdGlkLnBpZCAoKSk7CisJcmV0dXJuIHBkX2FjdGl2YXRlIChwdGlkKTsK ICAgICB9CiAKLSAgcmV0dXJuIHBkX3VwZGF0ZSAocHRpZC5waWQgKCkpOwor ICByZXR1cm4gcGRfdXBkYXRlIChwdGlkKTsKIH0KIAogLyogUmVjb3JkIHRo YXQgdGhlIDY0LWJpdCBnZW5lcmFsLXB1cnBvc2UgcmVnaXN0ZXJzIGNvbnRh aW4gVkFMUy4gICovCmRpZmYgLS1naXQgYS9nZGIvcnM2MDAwLWFpeC1uYXQu YyBiL2dkYi9yczYwMDAtYWl4LW5hdC5jCmluZGV4IDJhYzFmNmU3MGI2Li5m ZTdjYTRmM2YyYSAxMDA2NDQKLS0tIGEvZ2RiL3JzNjAwMC1haXgtbmF0LmMK KysrIGIvZ2RiL3JzNjAwMC1haXgtbmF0LmMKQEAgLTk5LDYgKzk5LDggQEAg Y2xhc3MgcnM2MDAwX25hdF90YXJnZXQgZmluYWwgOiBwdWJsaWMgaW5mX3B0 cmFjZV90YXJnZXQKICAgICAgc3VwcG9ydC4gICovCiAgIHZvaWQgZm9sbG93 X2ZvcmsgKGluZmVyaW9yICosIHB0aWRfdCwgdGFyZ2V0X3dhaXRraW5kLCBi b29sLCBib29sKSBvdmVycmlkZTsKIAorICBzdGQ6OnN0cmluZyBwaWRfdG9f c3RyIChwdGlkX3QpIG92ZXJyaWRlOworCiBwcm90ZWN0ZWQ6CiAKICAgdm9p ZCBwb3N0X3N0YXJ0dXBfaW5mZXJpb3IgKHB0aWRfdCBwdGlkKSBvdmVycmlk ZTsKQEAgLTYxOSw2ICs2MjEsNjQgQEAgcnM2MDAwX25hdF90YXJnZXQ6Onhm ZXJfcGFydGlhbCAoZW51bSB0YXJnZXRfb2JqZWN0IG9iamVjdCwKICAgICB9 CiB9CiAKKy8qIFNlYXJjaCB0aHJvdWdoIHRoZSBsaXN0IG9mIGFsbCBrZXJu ZWwgdGhyZWFkcyBmb3IgdGhlIHRocmVhZAorICAgdGhhdCBoYXMgc3RvcHBl ZCBvbiBhIFNJR1RSQVAgb3IgU0lHSU5UIHNpZ25hbCwgYW5kIHJldHVybgor ICAgaXRzIFRJRC4gIFJldHVybiAwIGlmIG5vbmUgZm91bmQuICAqLworCitz dGF0aWMgdGlkX3QKK2dldF9zaWduYWxlZF90aHJlYWRfcnM2MDAwIChpbnQg cGlkKQoreworICBzdHJ1Y3QgdGhyZHNpbmZvNjQgdGhyaW5mOworICB0aWRf dCBrdGlkID0gMDsKKworICB3aGlsZSAoMSkKKyAgICB7CisgICAgICBpZiAo Z2V0dGhyZHMgKHBpZCwgJnRocmluZiwKKyAgICAgICAgICAgICAgICAgICAg c2l6ZW9mICh0aHJpbmYpLCAma3RpZCwgMSkgIT0gMSkKKyAgICAgICAgYnJl YWs7CisKKyAgICAgIGlmICh0aHJpbmYudGlfY3Vyc2lnICE9IDApCisgICAg ICAgIHJldHVybiB0aHJpbmYudGlfdGlkOworICAgIH0KKworICAvKiBEaWRu J3QgZmluZCBhbnkgdGhyZWFkIHN0b3BwZWQgb24gYSBTSUdUUkFQIHNpZ25h bC4gICovCisgIHJldHVybiAwOworfQorCisvKiBJZiBteSBwcm9jZXNzIGlz IHB0aHJlYWRlZCBJIG5lZWQgdG8gcmV0dXJuIHRoYXQgcHRpZCBlbHNlIHB0 aWRfdAorICAgKHBpZCkuICAqLworCitzdGF0aWMgcHRpZF90CitmaW5kX3Ro ZV9yZXR1cm5fcHRpZCAocGlkX3QgcGlkKQoreworICBwdGlkX3QgcHRpZCA9 IHB0aWRfdCAocGlkKTsKKyAgcHJvY2Vzc19zdHJhdHVtX3RhcmdldCAqcHJv Y190YXJnZXQKKyAgICAgICAgPSBjdXJyZW50X2luZmVyaW9yICgpLT5wcm9j ZXNzX3RhcmdldCAoKTsKKyAgaW5mZXJpb3IgKmluZiA9IGZpbmRfaW5mZXJp b3JfcGlkIChwcm9jX3RhcmdldCwgcGlkKTsKKyAgdGhyZWFkX2luZm8gKnRw ID0gZmluZF90aHJlYWRfcHRpZCAoaW5mLCBwdGlkX3QgKHBpZCkpOworICBp ZiAodHAgPT0gbnVsbHB0cikKKyAgICBmb3IgKHRocmVhZF9pbmZvICp0cDEg OiBpbmYtPnRocmVhZHMgKCkpCisgICAgICAgaWYgKHRwMS0+cHRpZC5sd3Ag KCkgPT0gZ2V0X3NpZ25hbGVkX3RocmVhZF9yczYwMDAgKHBpZCkpCisgICAg ICAgICByZXR1cm4gdHAxLT5wdGlkOworICByZXR1cm4gcHRpZDsKK30KKwor LyogUmV0dXJuaW5nICJ0aHJlYWQiIG9yICJwcm9jZXNzIiBpbmZvIGFzIGNv bnRyb2wgY29tZXMgaGVyZSAKKyAgIGR1cmluZyBhIHByb2Nlc3Mgc3dpdGNo IGluIG11bHRpIHByb2Nlc3MgZGVidWdnaW5nLiAgVGhpcyAKKyAgIGlzIG5l ZWRlZCBmb3IgImluZm8gdGhyZWFkcyIgY29tbWFuZCBhcyBhIHByb2Nlc3Mg Y2FuIGJlCisgICB0aHJlYWRlZCBvciBub24gdGhyZWFkZWQgaW4gbXVsdGkg cHJvY2VzcyBjYXNlLiAgKi8KKworc3RkOjpzdHJpbmcKK3JzNjAwMF9uYXRf dGFyZ2V0OjpwaWRfdG9fc3RyIChwdGlkX3QgcHRpZCkKK3sKKyAgaWYgKHB0 aWQudGlkICgpICE9IDApCisgICAgcmV0dXJuIHN0cmluZ19wcmludGYgKF8o IlRocmVhZCAlcyIpLCBwdWxvbmdlc3QgKHB0aWQudGlkICgpKSk7CisKKyAg ZWxzZQorICAgIHJldHVybiBzdHJpbmdfcHJpbnRmIChfKCJQcm9jZXNzICVz IiksIHB1bG9uZ2VzdCAocHRpZC5waWQgKCkpKTsKK30KKworCiAvKiBXYWl0 IGZvciB0aGUgY2hpbGQgc3BlY2lmaWVkIGJ5IFBUSUQgdG8gZG8gc29tZXRo aW5nLiAgUmV0dXJuIHRoZQogICAgcHJvY2VzcyBJRCBvZiB0aGUgY2hpbGQs IG9yIE1JTlVTX09ORV9QVElEIGluIGNhc2Ugb2YgZXJyb3I7IHN0b3JlCiAg ICB0aGUgc3RhdHVzIGluICpPVVJTVEFUVVMuICAqLwpAQCAtNjcyLDcgKzcz Miw3IEBAIHJzNjAwMF9uYXRfdGFyZ2V0Ojp3YWl0IChwdGlkX3QgcHRpZCwg c3RydWN0IHRhcmdldF93YWl0c3RhdHVzICpvdXJzdGF0dXMsCiAJICAgICAg aWYgKHBhcmVudF9waWQgPiAwKQogCQl7CiAJCSAgb3Vyc3RhdHVzLT5zZXRf Zm9ya2VkIChwdGlkX3QgKHBpZCkpOwotCQkgIHJldHVybiBwdGlkX3QgKHBh cmVudF9waWQpOworCQkgIHJldHVybiBmaW5kX3RoZV9yZXR1cm5fcHRpZCAo cGFyZW50X3BpZCk7CiAJCX0KIAkgICAgICBhaXhfcmVtZW1iZXJfY2hpbGQg KHBpZCk7CiAJICAgIH0KQEAgLTY4Nyw3ICs3NDcsNyBAQCByczYwMDBfbmF0 X3RhcmdldDo6d2FpdCAocHRpZF90IHB0aWQsIHN0cnVjdCB0YXJnZXRfd2Fp dHN0YXR1cyAqb3Vyc3RhdHVzLAogCSAgICAgIGlmIChjaGlsZF9waWQgPiAw KQogCQl7CiAJCSAgb3Vyc3RhdHVzLT5zZXRfZm9ya2VkIChwdGlkX3QgKGNo aWxkX3BpZCkpOwotCQkgIHJldHVybiBwdGlkX3QgKHBpZCk7CisJCSAgcmV0 dXJuIGZpbmRfdGhlX3JldHVybl9wdGlkIChwaWQpOwogCQl9CiAJICAgICAg YWl4X3JlbWVtYmVyX3BhcmVudCAocGlkKTsKIAkgICAgfQpAQCAtNzEyLDcg Kzc3Miw3IEBAIHJzNjAwMF9uYXRfdGFyZ2V0Ojp3YWl0IChwdGlkX3QgcHRp ZCwgc3RydWN0IHRhcmdldF93YWl0c3RhdHVzICpvdXJzdGF0dXMsCiAgIGVs c2UKICAgICAqb3Vyc3RhdHVzID0gaG9zdF9zdGF0dXNfdG9fd2FpdHN0YXR1 cyAoc3RhdHVzKTsKIAotICByZXR1cm4gcHRpZF90IChwaWQpOworICByZXR1 cm4gZmluZF90aGVfcmV0dXJuX3B0aWQgKHBpZCk7CiB9CiAMCiAKLS0gCjIu MzEuMQoK --_004_CH2PR15MB35447EE88C64F7F36A0C61F5D61D9CH2PR15MB3544namp_--