From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Cyril Arnould Newsgroups: gmane.emacs.bugs Subject: bug#63752: 28.2; GCC 13.1 breaks Emacs subprocess handling when built with -D_FORTIFY_SOURCE Date: Thu, 6 Jul 2023 19:28:40 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="_004_AS4PR10MB61106EB0D04EEE74FD466CFDE32CAAS4PR10MB6110EURP_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8012"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "acorallo@gnu.org" , =?UTF-8?Q?Andr=C3=A1s?= Svraka , "63752@debbugs.gnu.org" <63752@debbugs.gnu.org> To: "eliz@gnu.org" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 06 21:29:24 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qHUfL-0001tk-D3 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Jul 2023 21:29:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qHUf2-0005Xf-GL; Thu, 06 Jul 2023 15:29:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qHUf0-0005XX-VT for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2023 15:29:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qHUf0-0005gh-NT for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2023 15:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qHUf0-00077O-DP for bug-gnu-emacs@gnu.org; Thu, 06 Jul 2023 15:29:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Cyril Arnould Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 06 Jul 2023 19:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63752 X-GNU-PR-Package: emacs Original-Received: via spool by 63752-submit@debbugs.gnu.org id=B63752.168867173027340 (code B ref 63752); Thu, 06 Jul 2023 19:29:02 +0000 Original-Received: (at 63752) by debbugs.gnu.org; 6 Jul 2023 19:28:50 +0000 Original-Received: from localhost ([127.0.0.1]:42111 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHUen-00076t-SH for submit@debbugs.gnu.org; Thu, 06 Jul 2023 15:28:50 -0400 Original-Received: from mail-vi1eur05olkn2033.outbound.protection.outlook.com ([40.92.90.33]:58465 helo=EUR05-VI1-obe.outbound.protection.outlook.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qHUek-00076f-US for 63752@debbugs.gnu.org; Thu, 06 Jul 2023 15:28:48 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QmawawmaU9KoJrKGHp4OCRYSIApHPZHxasKtMexNaOb5nJofaRDoogtSvw0Xh1ySoAuTbS+xDHxXmIVfwPbvHFpq+9f7n9b4G5NmcLEQrlpuN0UZHQ42b8+ndoOqsgHHdFCkVNfS1mHQoB11WQZxNxWyBK3QLd7Gv5Cwh5yja8PeSPenrh40Xua71enN3LoWjgR9N2hVXOs97OZb4svm9zOul0Ao3Q/c0M4kx5DVwnRvO+bGwtgPFrKao7PVRR743HkgVqSSeYc8+Jl6n31K/r4FvLUeMtJHLXiMXzmc7711KuSc8lHiXvTCm2LP9Tz9cbOXI/ZWFn/s2Y22zFbciw== 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=BLypIYdjWSPZYuoIHFEiUWJe4DgjdtOQhGNCzhRtdAk=; b=loyZxhHuo7w2HCrdF5O0QfrtrOu0ijnG4DOpnmNKJL1DloabibYp7nzvOinFmFZpssSqdxzvFePq/IOn/R9kFX7nxnKomqBRVRUZAu8XKpH3n9OEct0cRPGwj+Lput5khzXkqeyYgETnONjXebAUT1NQFtl8TbtM7AIhbyDAn6dfJ0Tu8j5mR1zDRZbOYWNhnl6CrqiCON5hgZKFpz/wZNkHmmuD3FKEPAyG+vv2c5cc3L4bR1Sk+WOQJ/g/XhFZ2d7Z5E27Rieooy1jsg5hrMWUQQ5obOIDq6K+9PI1vdY4PENBZNl52Zbx8hSJ23la5nsL0GvuChdTyjmHpwtlEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BLypIYdjWSPZYuoIHFEiUWJe4DgjdtOQhGNCzhRtdAk=; b=aVSmmcVl1qhWjrrkwBdejJpiNuIjTJKTGv/9yTmdO4VLlRCQPYjaRHqlO7eXwUoW3kNYF+ck44YbfOqqi9rVkQR39kOYTrpfdeygIt+/4NvK94RCkU1LsnMhJ24w0HHZR9sbu0tIZsE8Sd2HAdW6oOELidzTQqWG9j60LHPcejVtTr3zhHTY77hZIImqi4nfPxLpii7jnMlKx2OY36CDMWWjJR8rBUMO+13jBeb/PsdeaYpZ175nWuCJ09B+BG8vBNbyJhU6ApGPH/fzfrxqgHXHr/V8f2YHbcfJBJWZ0jDVtl0TXmUVZBVqZrkIb1p+pVaYldjlnaBAH9+DsdoUmA== Original-Received: from AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:582::17) by DB4PR10MB6239.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:381::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6565.17; Thu, 6 Jul 2023 19:28:40 +0000 Original-Received: from AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM ([fe80::7a2:effb:6bb7:ada1]) by AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM ([fe80::7a2:effb:6bb7:ada1%7]) with mapi id 15.20.6565.016; Thu, 6 Jul 2023 19:28:40 +0000 Thread-Topic: bug#63752: 28.2; GCC 13.1 breaks Emacs subprocess handling when built with -D_FORTIFY_SOURCE Thread-Index: AQHZsD/W5Viq9J4jO0yEztlnCc96Ig== Accept-Language: de-CH, en-US Content-Language: de-CH X-MS-Has-Attach: yes x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [zvipVUa4z6g6vYGm9kz+8911XO5m1IGQ] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AS4PR10MB6110:EE_|DB4PR10MB6239:EE_ x-ms-office365-filtering-correlation-id: 882ebb6a-cad3-44ad-8acc-08db7e5733e0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yJVMGJdzVXx06ncoin0zslUrHgLWTbIFFA+HdpZKx2SKQWRRlQbykGjTXkHyI92rV403dhEvscMQ92gPsRPqjep3UhPp5YIxb4ZLeQlAke26VXtxNMPaIXwsYfF/X7O4unjsamC2RPKojmzXrrFVTZkzt71atZua7025A9yTpXsG9xdv3DKg4r3ClUeGhzQEIMYs4nnPMevz7hLJiR1gnboAkW+6IHnVGtsVGDuon4zB9TkifFCu4xoLmV/i7jZS94wJWdZnY9bs5mOLzk9aPDonQb79fwutGccKLClAKydGXNEzXgauAnujAp337wBWKZlnKOpK63TnLaz9A7KwOyFaoiJGM/s41A8p/6oT4SxorDh4aWAUrvAJYC6KXK9ctIU/UxSXHI/hLgazRjPk4Z7+A5oPWeAHvVGUQcpY+fIZTo554xgSD9fNAMBnI5jE1qRQt7B/G7Ha+2sxbJQmc+/JfVP45WySWC2QAC7ou7WUEF1j/j8RcOMh5u8zd5gy37r6PpKftkb7fYA2ZmJBm5fKvzWzciqamb0LCxkytVQJ97J2kVIc/YgoFBU+pHX/ x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: ROmtMb6unYEFWvFEjoaXu/yM6zLKzWOxsgWzXZLQ/9CufJIdFqifFFIxoX1x7a9L9OT/jmiDbeWr96BLTvYwMgDLdt2lu+OCuyaCktKcWLutZIW6Pz4Udy+MmcdDH0gv3qVjgoZ0g65b7wyNCaY4v3EdSGVpMNExTqmbY2s7xq/w7wtyfJLLB4sxaBFoFM/s/0m0yi35oUg44uQjtEu9WDda22L8cuDjqrxXWpYPVZXfgptZzZln4kafc5fglQ/vNbymxLLiisWlcvBBDQHbgfmOQrm1qUZRDlTBvhNUcZerW/W6UGuCegWX9D9x6kb7qF1XpiqkUuHdbh0PN9UgXGC/GagIfMb5pY8LsEOgOC9WQeJx74ZCkG/+3zM35N9H/VB9PmtgUScP13Dk77UxW1jUh13H15HP6z6DCJbFRlROuRiOCXLzf1JTcDSK7kCkLjvEs+nvs7B5KWpF2ilxmJxaJie+Hf3XmizOJMaPAAACpYBGVExGbkAsrXY74aSGAokHolJlKOMnh8/M6yuqCnQ0sZ0XM0c+3EvcXYQLZHL/T2zLKOufcgHUa1T7yEjcqwY4IAJitJYjnWBNN5X4CI3jcCFEU1Wdjo7/ORHEQRmsutmj4GS32feT93V5+djSoS18ZlZ4a0cOgqrJ2ks9dvBzZVOYdXj7zS0A4kLCMinsSo47O8J/8V7yj+6AxtDJstjvAw36qnZosJL2OOTIX2JhNfwkFjha+OjD3eOFHcamBUTy5wAr4Z5sHM IbkE9RnCDSu9MEnbl6SLekDlp3oweLy7F/O+olLCdLjdEYQ8jnsC0EKivb3UqjGw0R13rUxs2VqVURllDBmrz/5oq9vQTeERMp X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS4PR10MB6110.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 882ebb6a-cad3-44ad-8acc-08db7e5733e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2023 19:28:40.0282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR10MB6239 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264697 Archived-At: --_004_AS4PR10MB61106EB0D04EEE74FD466CFDE32CAAS4PR10MB6110EURP_ Content-Type: multipart/alternative; boundary="_000_AS4PR10MB61106EB0D04EEE74FD466CFDE32CAAS4PR10MB6110EURP_" --_000_AS4PR10MB61106EB0D04EEE74FD466CFDE32CAAS4PR10MB6110EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It's too bad the problem goes away under GDB, because we don't even > know whether the crash is due to some fatal error in the Emacs code, > or due to those extra-checking routines inserted into the code by the > FORTIFY option. IOW, it could be that the problem happens because the > FORTIFY routines don't understand something Emacs does and consider it > a bug worthy of aborting the program. Oh, I think there might be some confusion with #63365, sorry if I haven't been precise enough. This fortify bug does *not* go away under GDB (unless I'm misunderstanding). I get the following output when running the binary compiled with -D_FORTIFY_SOURCE: $ gdb -q --args ./src/emacs -Q --eval '(async-shell-command "dir")' Reading symbols from ./src/emacs... (gdb) run Starting program: I:\Git\emacs\src\emacs.exe -Q --eval "(async-shell-comman= d \"dir\")" [New Thread 15740.0x22e0] [New Thread 15740.0x2b50] [New Thread 15740.0x10cc] [New Thread 15740.0x4f4] [New Thread 15740.0x3eac] [New Thread 15740.0x3c80] The output then continues once I close the window: [Thread 15740.0x4f4 exited with code 0] [New Thread 15740.0x3b00] [New Thread 15740.0x9ac] [Thread 15740.0x3c80 exited with code 0] [Thread 15740.0x10cc exited with code 0] [Thread 15740.0x2b50 exited with code 0] [Thread 15740.0x22e0 exited with code 0] [Thread 15740.0x3b00 exited with code 0] [Thread 15740.0x3eac exited with code 0] [Thread 15740.0x9ac exited with code 0] [Inferior 1 (process 15740) exited normally] (gdb) quit When running the binary where sysdep.o is compiled without -D_FORTIFY_SOURCE, I get the following instead: $ gdb -q --args ./src/emacs -Q --eval '(async-shell-command "dir")' Reading symbols from ./src/emacs... (gdb) run Starting program: I:\Git\emacs\src\emacs.exe -Q --eval "(async-shell-comman= d \"dir\")" [New Thread 4364.0x36d4] [New Thread 4364.0x3f38] [New Thread 4364.0x3eec] [New Thread 4364.0x924] [New Thread 4364.0x38bc] [New Thread 4364.0x2f8c] [Thread 4364.0x2f8c exited with code 0] And once I close the window: [Thread 4364.0x924 exited with code 0] [Thread 4364.0x36d4 exited with code 0] [Thread 4364.0x3eec exited with code 0] [Thread 4364.0x3f38 exited with code 0] [Thread 4364.0x38bc exited with code 0] [Inferior 1 (process 4364) exited normally] (gdb) quit The big difference being that in the latter case, the last thread exits immediately (which I assume is the "dir" command), while with -D_FORTIFY_SOURCE the thread only exits once I close the window. I can perform further tests with GDB of course. > Another interesting question is why the problems happen only in Emacs > built with native compilation. Do we use emacs_read or its callers in > some special ways when they are called from comp.c or comp.el? Again, there's some confusion with #63365. AFAICT, the fortify bug occurs regardless of whether Emacs is built --with-native-compilation or not. The third emacs-28.2 release on MSYS2 had the fortify bug and was compiled --with-native-compilation. So far in *this* bug report I have been using the default ./configure options, so native compilation should be off in my objdumps. In fact, I think the two bugs are not related at all. #63365 occurs regardless of whether Emacs is built with or without -D_FORTIFY_SOURCE; see the fourth and fifth release of Emacs on MSYS2. Now, to make sure the two are not related, I've now repeated the process with the following flags: CFLAGS=3D'-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=3D2 -fno-optimize-sibling= -calls' The fortify bug was still there, so it doesn't seem like -foptimize-sibling-calls is the root cause for #63752. The objdump of sysdep1.o is slightly different from the one compiled with -foptimize-sibling-calls, I've attached it in case someone wants to take a look but I don't think it's relevant. > Maybe we should ask the MinGW64 folks who implemented the FORTIFY > support for MinGW64 GCC to join this discussion and help us figure out > which part(s) of this puzzle are relevant and why? Cyril, can you > reach out to them and ask them help us out here? Sure, I've opened a support request: https://sourceforge.net/p/mingw-w64/support-requests/193/ --_000_AS4PR10MB61106EB0D04EEE74FD466CFDE32CAAS4PR10MB6110EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

> It's too bad the problem goes away under GDB, b= ecause we don't even

> know whether the crash is due to some fatal err= or in the Emacs code,

> or due to those extra-checking routines inserte= d into the code by the

> FORTIFY option.  IOW, it could be that the= problem happens because the

> FORTIFY routines don't understand something Ema= cs does and consider it

> a bug worthy of aborting the program.

 

Oh, I think there might be some confusion with #6336= 5, sorry if I

haven't been precise enough. This fortify bug does *= not* go away under

GDB (unless I'm misunderstanding). I get the followi= ng output when

running the binary compiled with -D_FORTIFY_SOURCE:<= /p>

 

$ gdb -q --args ./src/emacs -Q --eval '(async-shell-= command "dir")'

Reading symbols from ./src/emacs...

(gdb) run

Starting program: I:\Git\emacs\src\emacs.exe -Q --ev= al "(async-shell-command \"dir\")"

[New Thread 15740.0x22e0]

[New Thread 15740.0x2b50]

[New Thread 15740.0x10cc]

[New Thread 15740.0x4f4]

[New Thread 15740.0x3eac]

[New Thread 15740.0x3c80]

 

The output then continues once I close the window: <= /p>

 

[Thread 15740.0x4f4 exited with code 0]

[New Thread 15740.0x3b00]

[New Thread 15740.0x9ac]

[Thread 15740.0x3c80 exited with code 0]

[Thread 15740.0x10cc exited with code 0]

[Thread 15740.0x2b50 exited with code 0]

[Thread 15740.0x22e0 exited with code 0]

[Thread 15740.0x3b00 exited with code 0]

[Thread 15740.0x3eac exited with code 0]

[Thread 15740.0x9ac exited with code 0]

[Inferior 1 (process 15740) exited normally]

(gdb) quit

 

When running the binary where sysdep.o is compiled w= ithout

-D_FORTIFY_SOURCE, I get the following instead:

 

$ gdb -q --args ./src/emacs -Q --eval '(async-shell-= command "dir")'

Reading symbols from ./src/emacs...

(gdb) run

Starting program: I:\Git\emacs\src\emacs.exe -Q --ev= al "(async-shell-command \"dir\")"

[New Thread 4364.0x36d4]

[New Thread 4364.0x3f38]

[New Thread 4364.0x3eec]

[New Thread 4364.0x924]

[New Thread 4364.0x38bc]

[New Thread 4364.0x2f8c]

[Thread 4364.0x2f8c exited with code 0]

 

And once I close the window:

 

[Thread 4364.0x924 exited with code 0]

[Thread 4364.0x36d4 exited with code 0]

[Thread 4364.0x3eec exited with code 0]

[Thread 4364.0x3f38 exited with code 0]

[Thread 4364.0x38bc exited with code 0]

[Inferior 1 (process 4364) exited normally]

(gdb) quit

 

The big difference being that in the latter case, th= e last thread exits

immediately (which I assume is the "dir" c= ommand), while with

-D_FORTIFY_SOURCE the thread only exits once I close= the window. I can

perform further tests with GDB of course.

 

> Another interesting question is why the problem= s happen only in Emacs

> built with native compilation.  Do we use = emacs_read or its callers in

> some special ways when they are called from com= p.c or comp.el?

 

Again, there's some confusion with #63365. AFAICT, t= he fortify bug

occurs regardless of whether Emacs is built --with-n= ative-compilation or

not. The third emacs-28.2 release on MSYS2 had the f= ortify bug and was

compiled --with-native-compilation. So far in *this*= bug report I have

been using the default ./configure options, so nativ= e compilation should

be off in my objdumps.

 

In fact, I think the two bugs are not related at all= . #63365 occurs

regardless of whether Emacs is built with or without= -D_FORTIFY_SOURCE;

see the fourth and fifth release of Emacs on MSYS2.<= /p>

 

Now, to make sure the two are not related, I've now = repeated the process

with the following flags:

 

CFLAGS=3D'-g3 -O2 -gdwarf-2 -Wp,-D_FORTIFY_SOURCE=3D= 2 -fno-optimize-sibling-calls'

 

The fortify bug was still there, so it doesn't seem = like

-foptimize-sibling-calls is the root cause for #6375= 2. The objdump of

sysdep1.o is slightly different from the one compile= d with

-foptimize-sibling-calls, I've attached it in case s= omeone wants to take

a look but I don't think it's relevant.

 

> Maybe we should ask the MinGW64 folks who imple= mented the FORTIFY

> support for MinGW64 GCC to join this discussion= and help us figure out

> which part(s) of this puzzle are relevant and w= hy?  Cyril, can you

> reach out to them and ask them help us out here= ?

 

Sure, I've opened a support request:

 

https://sourceforge.net/p/mingw-w64/support-requests= /193/

--_000_AS4PR10MB61106EB0D04EEE74FD466CFDE32CAAS4PR10MB6110EURP_-- --_004_AS4PR10MB61106EB0D04EEE74FD466CFDE32CAAS4PR10MB6110EURP_ Content-Type: text/plain; name="sysdep1-fortify-nosiblings.txt" Content-Description: sysdep1-fortify-nosiblings.txt Content-Disposition: attachment; filename="sysdep1-fortify-nosiblings.txt"; size=4368; creation-date="Thu, 06 Jul 2023 19:27:36 GMT"; modification-date="Thu, 06 Jul 2023 19:27:36 GMT" Content-Transfer-Encoding: base64 DQpzcmMvc3lzZGVwMS5vOiAgICAgZmlsZSBmb3JtYXQgcGUteDg2LTY0DQoNCg0KRGlzYXNzZW1i bHkgb2Ygc2VjdGlvbiAudGV4dDoNCg0KMDAwMDAwMDAwMDAwMDAwMCA8ZW1hY3NfaW50cl9yZWFk PjoNCiAgIGlmIElOVEVSUlVQVElCTEUsIGFuZCB0aGVuIHJldHJ5IHRoZSByZWFkIHVubGVzcyBx dWl0dGluZy4NCiAgIFJldHVybiB0aGUgbnVtYmVyIG9mIGJ5dGVzIHJlYWQsIHdoaWNoIG1pZ2h0 IGJlIGxlc3MgdGhhbiBOQllURS4NCiAgIE9uIGVycm9yLCBzZXQgZXJybm8gdG8gYSB2YWx1ZSBv dGhlciB0aGFuIEVJTlRSLCBhbmQgcmV0dXJuIC0xLiAgKi8NCnN0YXRpYyBwdHJkaWZmX3QNCmVt YWNzX2ludHJfcmVhZCAoaW50IGZkLCB2b2lkICpidWYsIHB0cmRpZmZfdCBuYnl0ZSwgYm9vbCBp bnRlcnJ1cHRpYmxlKQ0Kew0KICAgMDoJNDEgNTYgICAgICAgICAgICAgICAgCXB1c2ggICAlcjE0 DQogICAyOgk0MSA1NSAgICAgICAgICAgICAgICAJcHVzaCAgICVyMTMNCiAgIDQ6CTQxIDU0ICAg ICAgICAgICAgICAgIAlwdXNoICAgJXIxMg0KICAgNjoJNTUgICAgICAgICAgICAgICAgICAgCXB1 c2ggICAlcmJwDQogICA3Ogk1NyAgICAgICAgICAgICAgICAgICAJcHVzaCAgICVyZGkNCiAgIDg6 CTU2ICAgICAgICAgICAgICAgICAgIAlwdXNoICAgJXJzaQ0KICAgOToJNTMgICAgICAgICAgICAg ICAgICAgCXB1c2ggICAlcmJ4DQogICBhOgk0OCA4MyBlYyAyMCAgICAgICAgICAJc3ViICAgICQw eDIwLCVyc3ANCiAgIGU6CTRjIDhiIDJkIDAwIDAwIDAwIDAwIAltb3YgICAgMHgwKCVyaXApLCVy MTMgICAgICAgICMgMTUgPGVtYWNzX2ludHJfcmVhZCsweDE1Pg0KICAgIHsNCiAgICAgIGlmIChp bnRlcnJ1cHRpYmxlKQ0KCW1heWJlX3F1aXQgKCk7DQogICAgICByZXN1bHQgPSByZWFkIChmZCwg YnVmLCBuYnl0ZSk7DQogICAgfQ0KICB3aGlsZSAocmVzdWx0IDwgMCAmJiBlcnJubyA9PSBFSU5U Uik7DQogIDE1Ogk0YyA4YiAzNSAwMCAwMCAwMCAwMCAJbW92ICAgIDB4MCglcmlwKSwlcjE0ICAg ICAgICAjIDFjIDxlbWFjc19pbnRyX3JlYWQrMHgxYz4NCnsNCiAgMWM6CTQxIDg5IGNjICAgICAg ICAgICAgIAltb3YgICAgJWVjeCwlcjEyZA0KICAxZjoJNDggODkgZDUgICAgICAgICAgICAgCW1v diAgICAlcmR4LCVyYnANCiAgMjI6CTQ0IDg5IGNmICAgICAgICAgICAgIAltb3YgICAgJXI5ZCwl ZWRpDQogICAgICByZXN1bHQgPSByZWFkIChmZCwgYnVmLCBuYnl0ZSk7DQogIDI1Ogk0NCA4OSBj NiAgICAgICAgICAgICAJbW92ICAgICVyOGQsJWVzaQ0KICAyODoJZWIgMjIgICAgICAgICAgICAg ICAgCWptcCAgICA0YyA8ZW1hY3NfaW50cl9yZWFkKzB4NGM+DQogIDJhOgk2NiAwZiAxZiA0NCAw MCAwMCAgICAJbm9wdyAgIDB4MCglcmF4LCVyYXgsMSkNCg0KX19taW5nd19ib3NfZXh0ZXJuX292 cg0KaW50IF9yZWFkKGludCBfX2ZoLCB2b2lkICogX19kc3QsIHVuc2lnbmVkIGludCBfX24pDQp7 DQogIF9fbWluZ3dfYm9zX3B0cl9jaGtfd2FybihfX2RzdCwgX19uLCAwKTsNCiAgcmV0dXJuIF9f bWluZ3dfY2FsbF9fcmVhZChfX2ZoLCBfX2RzdCwgX19uKTsNCiAgMzA6CTQxIDg5IGYwICAgICAg ICAgICAgIAltb3YgICAgJWVzaSwlcjhkDQogIDMzOgk0OCA4OSBlYSAgICAgICAgICAgICAJbW92 ICAgICVyYnAsJXJkeA0KICAzNjoJNDQgODkgZTEgICAgICAgICAgICAgCW1vdiAgICAlcjEyZCwl ZWN4DQogIDM5Ogk0MSBmZiBkNSAgICAgICAgICAgICAJY2FsbCAgIColcjEzDQogIDNjOgk0OCA2 MyBkOCAgICAgICAgICAgICAJbW92c2xxICVlYXgsJXJieA0KICB3aGlsZSAocmVzdWx0IDwgMCAm JiBlcnJubyA9PSBFSU5UUik7DQogIDNmOgk0OCA4NSBkYiAgICAgICAgICAgICAJdGVzdCAgICVy YngsJXJieA0KICA0MjoJNzkgMWMgICAgICAgICAgICAgICAgCWpucyAgICA2MCA8ZW1hY3NfaW50 cl9yZWFkKzB4NjA+DQogIDQ0Ogk0MSBmZiBkNiAgICAgICAgICAgICAJY2FsbCAgIColcjE0DQog IDQ3Ogk4MyAzOCAwNCAgICAgICAgICAgICAJY21wbCAgICQweDQsKCVyYXgpDQogIDRhOgk3NSAx NCAgICAgICAgICAgICAgICAJam5lICAgIDYwIDxlbWFjc19pbnRyX3JlYWQrMHg2MD4NCiAgICAg IGlmIChpbnRlcnJ1cHRpYmxlKQ0KICA0YzoJNDAgODQgZmYgICAgICAgICAgICAgCXRlc3QgICAl ZGlsLCVkaWwNCiAgNGY6CTc0IGRmICAgICAgICAgICAgICAgIAlqZSAgICAgMzAgPGVtYWNzX2lu dHJfcmVhZCsweDMwPg0KCW1heWJlX3F1aXQgKCk7DQogIDUxOgllOCAwMCAwMCAwMCAwMCAgICAg ICAJY2FsbCAgIDU2IDxlbWFjc19pbnRyX3JlYWQrMHg1Nj4NCiAgNTY6CWViIGQ4ICAgICAgICAg ICAgICAgIAlqbXAgICAgMzAgPGVtYWNzX2ludHJfcmVhZCsweDMwPg0KICA1ODoJMGYgMWYgODQg MDAgMDAgMDAgMDAgCW5vcGwgICAweDAoJXJheCwlcmF4LDEpDQogIDVmOgkwMCANCg0KICByZXR1 cm4gcmVzdWx0Ow0KfQ0KICA2MDoJNDggODkgZDggICAgICAgICAgICAgCW1vdiAgICAlcmJ4LCVy YXgNCiAgNjM6CTQ4IDgzIGM0IDIwICAgICAgICAgIAlhZGQgICAgJDB4MjAsJXJzcA0KICA2NzoJ NWIgICAgICAgICAgICAgICAgICAgCXBvcCAgICAlcmJ4DQogIDY4Ogk1ZSAgICAgICAgICAgICAg ICAgICAJcG9wICAgICVyc2kNCiAgNjk6CTVmICAgICAgICAgICAgICAgICAgIAlwb3AgICAgJXJk aQ0KICA2YToJNWQgICAgICAgICAgICAgICAgICAgCXBvcCAgICAlcmJwDQogIDZiOgk0MSA1YyAg ICAgICAgICAgICAgICAJcG9wICAgICVyMTINCiAgNmQ6CTQxIDVkICAgICAgICAgICAgICAgIAlw b3AgICAgJXIxMw0KICA2ZjoJNDEgNWUgICAgICAgICAgICAgICAgCXBvcCAgICAlcjE0DQogIDcx OgljMyAgICAgICAgICAgICAgICAgICAJcmV0DQogIDcyOgk2NiA2NiAyZSAwZiAxZiA4NCAwMCAJ ZGF0YTE2IGNzIG5vcHcgMHgwKCVyYXgsJXJheCwxKQ0KICA3OToJMDAgMDAgMDAgMDAgDQogIDdk OgkwZiAxZiAwMCAgICAgICAgICAgICAJbm9wbCAgICglcmF4KQ0KDQowMDAwMDAwMDAwMDAwMDgw IDxlbWFjc19yZWFkPjoNCg0KcHRyZGlmZl90DQplbWFjc19yZWFkIChpbnQgZmQsIHZvaWQgKmJ1 ZiwgcHRyZGlmZl90IG5ieXRlKQ0Kew0KICA4MDoJNDggODMgZWMgMjggICAgICAgICAgCXN1YiAg ICAkMHgyOCwlcnNwDQogIHJldHVybiBlbWFjc19pbnRyX3JlYWQgKGZkLCBidWYsIG5ieXRlLCBm YWxzZSk7DQogIDg0Ogk0NSAzMSBjOSAgICAgICAgICAgICAJeG9yICAgICVyOWQsJXI5ZA0KICA4 NzoJZTggNzQgZmYgZmYgZmYgICAgICAgCWNhbGwgICAwIDxlbWFjc19pbnRyX3JlYWQ+DQp9DQog IDhjOgk0OCA4MyBjNCAyOCAgICAgICAgICAJYWRkICAgICQweDI4LCVyc3ANCiAgOTA6CWMzICAg ICAgICAgICAgICAgICAgIAlyZXQNCiAgOTE6CTY2IDY2IDJlIDBmIDFmIDg0IDAwIAlkYXRhMTYg Y3Mgbm9wdyAweDAoJXJheCwlcmF4LDEpDQogIDk4OgkwMCAwMCAwMCAwMCANCiAgOWM6CTBmIDFm IDQwIDAwICAgICAgICAgIAlub3BsICAgMHgwKCVyYXgpDQoNCjAwMDAwMDAwMDAwMDAwYTAgPGVt YWNzX3JlYWRfcXVpdD46DQoNCi8qIExpa2UgZW1hY3NfcmVhZCwgYnV0IGFsc28gcHJvY2VzcyBx dWl0cyBhbmQgcGVuZGluZyBzaWduYWxzLiAgKi8NCnB0cmRpZmZfdA0KZW1hY3NfcmVhZF9xdWl0 IChpbnQgZmQsIHZvaWQgKmJ1ZiwgcHRyZGlmZl90IG5ieXRlKQ0Kew0KICBhMDoJNDggODMgZWMg MjggICAgICAgICAgCXN1YiAgICAkMHgyOCwlcnNwDQogIHJldHVybiBlbWFjc19pbnRyX3JlYWQg KGZkLCBidWYsIG5ieXRlLCB0cnVlKTsNCiAgYTQ6CTQxIGI5IDAxIDAwIDAwIDAwICAgIAltb3Yg ICAgJDB4MSwlcjlkDQogIGFhOgllOCA1MSBmZiBmZiBmZiAgICAgICAJY2FsbCAgIDAgPGVtYWNz X2ludHJfcmVhZD4NCn0NCiAgYWY6CTQ4IDgzIGM0IDI4ICAgICAgICAgIAlhZGQgICAgJDB4Mjgs JXJzcA0KICBiMzoJYzMgICAgICAgICAgICAgICAgICAgCXJldA0KICBiNDoJOTAgICAgICAgICAg ICAgICAgICAgCW5vcA0KICBiNToJOTAgICAgICAgICAgICAgICAgICAgCW5vcA0KICBiNjoJOTAg ICAgICAgICAgICAgICAgICAgCW5vcA0KICBiNzoJOTAgICAgICAgICAgICAgICAgICAgCW5vcA0K ICBiODoJOTAgICAgICAgICAgICAgICAgICAgCW5vcA0KICBiOToJOTAgICAgICAgICAgICAgICAg ICAgCW5vcA0KICBiYToJOTAgICAgICAgICAgICAgICAgICAgCW5vcA0KICBiYjoJOTAgICAgICAg ICAgICAgICAgICAgCW5vcA0KICBiYzoJOTAgICAgICAgICAgICAgICAgICAgCW5vcA0KICBiZDoJ OTAgICAgICAgICAgICAgICAgICAgCW5vcA0KICBiZToJOTAgICAgICAgICAgICAgICAgICAgCW5v cA0KICBiZjoJOTAgICAgICAgICAgICAgICAgICAgCW5vcA0K --_004_AS4PR10MB61106EB0D04EEE74FD466CFDE32CAAS4PR10MB6110EURP_--