From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id CABA93858D20 for ; Fri, 15 Nov 2024 08:49:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CABA93858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org CABA93858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1731660598; cv=none; b=h+rUwHfcCgdvSJcMmJ/+ppcMqklnJKBP3T5td/kx83mdcEn3IJaQ0LmAjZbFWtKHr+ji6i51BEMqJWNmpyQILvN2zNNAy8Nx1wb8kxul1msQRxgHVQ8XUlxgPi0QKNcalA/LXv30dopHXipqevLwuej+6Phl+gjzKXbJvMAVJEE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1731660598; c=relaxed/simple; bh=pVyod6IJ1Ys55LHU86rx92Dk8Wzj1RyLKedTLd3QMzE=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=UoYJYz6Y0jdVhD0Fn73rNj6Z5VDj1mxI9SnibejJp3r6rqlertFb37M/OaQTcyfW7OZ86Bjs+5PNXejGbLLOO466XKqo8z21eBqwpEE0t0VjvMOesVCvOlhcG6YAGDgWMqLpP/ggOf2z4q3SCh8o+xQig6WLcE3DiY+Z/QCal58= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CABA93858D20 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=MU/zGTHd; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=R+EeDiUR; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=MU/zGTHd; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=R+EeDiUR Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 8DB321F799; Fri, 15 Nov 2024 08:49:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1731660596; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kOLznDqsuMSRpkCLpwVH7uHtIXkz+mzcieADxBykTrA=; b=MU/zGTHdV0GPVM4xrwAQyBp8+UoAlwZ6El/fPbvyavv5gTKdMj755yuNiDZtnIkmQJNOJ3 33NLjIjNqgjlYhdhWzgpu4KLyCFPpBkBhg2Ks8DXpOyB6RoPt1YdeBqKZ3U4CjhPRdxDZf golMwg3vdAdy1bXd6QuaUA4plcjqx5E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1731660596; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kOLznDqsuMSRpkCLpwVH7uHtIXkz+mzcieADxBykTrA=; b=R+EeDiUReGEcSP+TDWeByW4jGzSHPhEL2Ojg2D7YUYILRFroTgbRp6V10IOW4bDWe1tBvy an5p/J7Y+Jz6sCBw== Authentication-Results: smtp-out2.suse.de; dkim=pass header.d=suse.de header.s=susede2_rsa header.b="MU/zGTHd"; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=R+EeDiUR DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1731660596; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kOLznDqsuMSRpkCLpwVH7uHtIXkz+mzcieADxBykTrA=; b=MU/zGTHdV0GPVM4xrwAQyBp8+UoAlwZ6El/fPbvyavv5gTKdMj755yuNiDZtnIkmQJNOJ3 33NLjIjNqgjlYhdhWzgpu4KLyCFPpBkBhg2Ks8DXpOyB6RoPt1YdeBqKZ3U4CjhPRdxDZf golMwg3vdAdy1bXd6QuaUA4plcjqx5E= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1731660596; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kOLznDqsuMSRpkCLpwVH7uHtIXkz+mzcieADxBykTrA=; b=R+EeDiUReGEcSP+TDWeByW4jGzSHPhEL2Ojg2D7YUYILRFroTgbRp6V10IOW4bDWe1tBvy an5p/J7Y+Jz6sCBw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 6A0B713485; Fri, 15 Nov 2024 08:49:56 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id In91GDQLN2eoNgAAD6G6ig (envelope-from ); Fri, 15 Nov 2024 08:49:56 +0000 Content-Type: multipart/mixed; boundary="------------alr5IUei6brI0LvzkmGpuYpK" Message-ID: <9fe35ea1-d99b-444d-bd1b-e3a1f108dd77@suse.de> Date: Fri, 15 Nov 2024 09:50:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv6] gdb: fix handling of DW_AT_entry_pc of inlined subroutines To: Andrew Burgess , gdb-patches@sourceware.org Cc: Bernd Edlinger References: <77d3058f18f7fa1d96243ec6165e14cfb5ebfc38.1730386643.git.aburgess@redhat.com> <6502c2236f1f02a82a50e97cf6e36d9be22c615a.1730805667.git.aburgess@redhat.com> <87cyizp7le.fsf@redhat.com> <8734jvoyrv.fsf@redhat.com> <87wmh5objj.fsf@redhat.com> Content-Language: en-US From: Tom de Vries In-Reply-To: <87wmh5objj.fsf@redhat.com> X-Rspamd-Queue-Id: 8DB321F799 X-Spam-Score: -3.41 X-Rspamd-Action: no action X-Spamd-Result: default: False [-3.41 / 50.00]; BAYES_HAM(-3.00)[100.00%]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_BASE64_TEXT(0.10)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain,text/x-log]; MX_GOOD(-0.01)[]; FUZZY_BLOCKED(0.00)[rspamd.com]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; RBL_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:104:10:150:64:97:from]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+]; ARC_NA(0.00)[]; FREEMAIL_ENVRCPT(0.00)[hotmail.de]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[hotmail.de]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; SPAMHAUS_XBL(0.00)[2a07:de40:b281:104:10:150:64:97:from]; RECEIVED_SPAMHAUS_BLOCKED_OPENRESOLVER(0.00)[2a07:de40:b281:106:10:150:64:167:received]; RCPT_COUNT_THREE(0.00)[3]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ATTACHMENT(0.00)[]; DKIM_TRACE(0.00)[suse.de:+]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:dkim,suse.de:mid,suse.de:email,imap1.dmz-prg2.suse.org:rdns,imap1.dmz-prg2.suse.org:helo] X-Rspamd-Server: rspamd1.dmz-prg2.suse.org X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 List-Id: This is a multi-part message in MIME format. --------------alr5IUei6brI0LvzkmGpuYpK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/14/24 20:33, Andrew Burgess wrote: > Tom de Vries writes: > >> On 11/13/24 17:59, Andrew Burgess wrote: >>> Andrew Burgess writes: >>> >>>> Andrew Burgess writes: >>>> >>>>> The entry PC for a DIE, e.g. an inline function, might not be the base >>>>> address of the DIE. Currently though, in block::entry_pc(), GDB >>>>> always returns the base address (low-pc or the first address of the >>>>> first range) as the entry PC. >>>>> >>>>> This commit extends the block class to carry the entry PC as a >>>>> separate member variable. Then the DWARF reader is extended to read >>>>> and set the entry PC for the block. Now in block::entry_pc(), if the >>>>> entry PC has been set, this is the value returned. >>>>> >>>>> If the entry-pc has not been set to a specific value then the old >>>>> behaviour of block::entry_pc() remains, GDB will use the block's base >>>>> address. Not every DIE will set the entry-pc, but GDB still needs to >>>>> have an entry-pc for every block, so the existing logic supplies the >>>>> entry-pc for any block where the entry-pc was not set. >>>>> >>>>> The DWARF-5 spec for reading the entry PC is a super-set of the spec >>>>> as found in DWARF-4. For example, if there is no DW_AT_entry_pc then >>>>> DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base >>>>> address, which is DW_AT_low_pc or the first address in the first range >>>>> specified by DW_AT_ranges if there is no DW_AT_low_pc. >>>>> >>>>> I have taken the approach of just implementing the DWARF-5 spec for >>>>> everyone. There doesn't seem to be any benefit to deliberately >>>>> ignoring a ranges based entry PC value for DWARF-4. If some naughty >>>>> compiler has emitted that, then lets use it. >>>>> >>>>> Similarly, DWARF-4 says that DW_AT_entry_pc is an address. DWARF-5 >>>>> allows an address or a constant, where the constant is an offset from >>>>> the base address. I allow both approaches for all DWARF versions. >>>>> There doesn't seem to be any downsides to this approach. >>>>> >>>>> I ran into an issue when testing this patch where GCC would have the >>>>> DW_AT_entry_pc point to an empty range. When GDB parses the ranges >>>>> any empty ranges are ignored. As a consequence, the entry-pc appears >>>>> to be outside the address range of a block. >>>>> >>>>> The empty range problem is certainly something that we can, and should >>>>> address, but that is not the focus of this patch, so for now I'm >>>>> ignoring that problem. What I have done is added a check: if the >>>>> DW_AT_entry_pc is outside the range of a block then the entry-pc is >>>>> ignored, GDB will then fall-back to its default algorithm for >>>>> computing the entry-pc. >>>>> >>>>> If/when in the future we address the empty range problem, these >>>>> DW_AT_entry_pc attributes will suddenly become valid and GDB will >>>>> start using them. Until then, GDB continues to operate as it always >>>>> has. >>>>> >>>>> An early version of this patch stored the entry-pc within the block >>>>> like this: >>>>> >>>>> std::optional m_entry_pc; >>>>> >>>>> However, a concern was raised that this, on a 64-bit host, effectively >>>>> increases the size of block by 16-bytes (8-bytes for the CORE_ADDR, >>>>> and 8-bytes for the std::optional's bool plus padding). >>>>> >>>>> If we remove the std::optional part and just use a CORE_ADDR then we >>>>> need to have a "special" address to indicate if m_entry_pc is in use >>>>> or not. I don't really like using special addresses; different >>>>> targets can access different address ranges, even zero is a valid >>>>> address on some targets. >>>>> >>>>> However, Bernd Edlinger suggested storing the entry-pc as an offset, >>>>> and I think that will resolve my concerns. So, we store the entry-pc >>>>> as a signed offset from the block's base address (the first address of >>>>> the first range, or the start() address value if there are now >>>>> ranges). Remember, ranges can be out of order, in which case the >>>>> first address of the first range might be greater than the entry-pc. >>>>> >>>>> When GDB needs to read the entry-pc we can add the offset onto the >>>>> blocks base address to recalculate it. >>>>> >>>>> With this done, on a 64-bit host, block only needs to increase by >>>>> 8-bytes. >>>>> >>>>> The inline-entry.exp test was originally contributed by Bernd here: >>>>> >>>>> https://inbox.sourceware.org/gdb-patches/AS1PR01MB94659E4D9B3F4A6006CC605FE4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com >>>>> >>>>> though I have made some edits, making more use of lib/gdb.exp >>>>> functions, making the gdb_test output patterns a little tighter, and >>>>> updating the test to run with Clang. I also moved the test to >>>>> gdb.opt/ as that seemed like a better home for it. >>>>> >>>>> Co-Authored-By: Bernd Edlinger >>>> >>>> I've pushed the patch attached below. The only changes are some minor >>>> test tweaks in order to get more of the 'check-all-boards' passing. >>>> There are still some failures on e.g. gold and fission based boards, but >>>> I think these might be due to issues with the board file. I'll post a >>>> patch for those soon. >>> >>> I'm aware that this patch has caused a regression on the buildbot[1]. I'm >>> investigating this but it will be at least tomorrow before I have fix. >>> >> >> In case this helps, I see the same assert in a large amount of ada >> test-cases. >> >> I reproduced the first one using gdb.ada/access_to_packed_array.exp, >> with system gcc 7 and then with gcc 8. With gcc 9 - 14, the assert no >> longer reproduces. > > Thanks Tom, > > I've posted a proposed fix here: > > https://inbox.sourceware.org/gdb-patches/23102df35a659d9ef4725d2d3822f08f2790e52d.1731612468.git.aburgess@redhat.com > > I would be really grateful if you could give this a try and let me know > if this fixes all the problems you are seeing. > Hi Andrew, it does fix all the regressions in ada test-cases. There's one problem left: a test-case introduced by the commit (gdb.opt/inline-entry.exp) fails with gcc 7 (not with gcc 8 and higher): ... FAIL: gdb.opt/inline-entry.exp: continue to foo FAIL: gdb.opt/inline-entry.exp: continue until exit ... Gdb.log attached. The test-case sets a breakpoint at foo and bar, and expects that the program: - stops at bar, - stops at foo, and - exits. This is what I see when using -O0. What happens instead (with -O2) is that the program: - stops at bar, - stops at bar again, - stops at foo, and - exits. For context, relevant code: ... inline __attribute__((always_inline)) int bar (int val) { if (global == val) return 1; foo (1); return 1; } int main (void) { if ((global && bar (1)) || bar (2)) return 0; return 1; } ... From what I can tell, what happened in source terms is that the compiler inlined the call "bar (1)", and then moved the first instruction of bar to before the &&: In disassembly: ... 00000000004003c0
: 4003c0: mov 0x1c5e(%rip),%eax # Load global to reg 4003c6: test %eax,%eax # If global is zero, set ZF 4003c8: mov 0x1c56(%rip),%eax # Local global to reg (1st of bar) 4003ce: je 4003d8 # If the ZF is set, skip "bar (1)" ... At first glance, gdb is behaving ok. Thanks, - Tom > I posted the fix as a new thread because it's not "fix a tiny bug" type > thing that I'm happy to just commit without giving others a chance to > fully review it. > > Thanks, > Andrew > --------------alr5IUei6brI0LvzkmGpuYpK Content-Type: text/x-log; charset=UTF-8; name="gdb.log" Content-Disposition: attachment; filename="gdb.log" Content-Transfer-Encoding: base64 VGVzdCBydW4gYnkgdnJpZXMgb24gRnJpIE5vdiAxNSAwOTowNDo0NiAyMDI0Ck5hdGl2ZSBj b25maWd1cmF0aW9uIGlzIHg4Nl82NC1wYy1saW51eC1nbnUKCgkJPT09IGdkYiB0ZXN0cyA9 PT0KClNjaGVkdWxlIG9mIHZhcmlhdGlvbnM6CiAgICB1bml4CgpSdW5uaW5nIHRhcmdldCB1 bml4ClVzaW5nIC91c3Ivc2hhcmUvZGVqYWdudS9iYXNlYm9hcmRzL3VuaXguZXhwIGFzIGJv YXJkIGRlc2NyaXB0aW9uIGZpbGUgZm9yIHRhcmdldC4KVXNpbmcgL3Vzci9zaGFyZS9kZWph Z251L2NvbmZpZy91bml4LmV4cCBhcyBnZW5lcmljIGludGVyZmFjZSBmaWxlIGZvciB0YXJn ZXQuClVzaW5nIC9kYXRhL3ZyaWVzL2dkYi9zcmMvZ2RiL3Rlc3RzdWl0ZS9jb25maWcvdW5p eC5leHAgYXMgdG9vbC1hbmQtdGFyZ2V0LXNwZWNpZmljIGludGVyZmFjZSBmaWxlLgpSdW5u aW5nIC9kYXRhL3ZyaWVzL2dkYi9zcmMvZ2RiL3Rlc3RzdWl0ZS9nZGIub3B0L2lubGluZS1l bnRyeS5leHAgLi4uCkV4ZWN1dGluZyBvbiBidWlsZDogcm0gLXJmIC9kYXRhL3ZyaWVzL2dk Yi9sZWFwLTE1LTUvYnVpbGQvZ2RiL3Rlc3RzdWl0ZS9vdXRwdXRzL2dkYi5vcHQvaW5saW5l LWVudHJ5ICAgICh0aW1lb3V0ID0gMzAwKQpidWlsdGluX3NwYXduIC1pZ25vcmUgU0lHSFVQ IHJtIC1yZiAvZGF0YS92cmllcy9nZGIvbGVhcC0xNS01L2J1aWxkL2dkYi90ZXN0c3VpdGUv b3V0cHV0cy9nZGIub3B0L2lubGluZS1lbnRyeQ0KZ2RiX2RvX2NhY2hlOiB1bml2ZXJzYWxf Y29tcGlsZV9vcHRpb25zX2MgKCAgKQpFeGVjdXRpbmcgb24gaG9zdDogZ2NjICAgLWZkaWFn bm9zdGljcy1jb2xvcj1uZXZlciAtYyAtbyAvZGF0YS92cmllcy9nZGIvbGVhcC0xNS01L2J1 aWxkL2dkYi90ZXN0c3VpdGUvdGVtcC8yNDg0L2Njb3B0cy5vIC9kYXRhL3ZyaWVzL2dkYi9s ZWFwLTE1LTUvYnVpbGQvZ2RiL3Rlc3RzdWl0ZS90ZW1wLzI0ODQvY2NvcHRzLmMgICAgKHRp bWVvdXQgPSAzMDApCmJ1aWx0aW5fc3Bhd24gLWlnbm9yZSBTSUdIVVAgZ2NjIC1mZGlhZ25v c3RpY3MtY29sb3I9bmV2ZXIgLWMgLW8gL2RhdGEvdnJpZXMvZ2RiL2xlYXAtMTUtNS9idWls ZC9nZGIvdGVzdHN1aXRlL3RlbXAvMjQ4NC9jY29wdHMubyAvZGF0YS92cmllcy9nZGIvbGVh cC0xNS01L2J1aWxkL2dkYi90ZXN0c3VpdGUvdGVtcC8yNDg0L2Njb3B0cy5jDQpnZXRfY29t cGlsZXJfaW5mbzogZ2NjLTctNS0wCkV4ZWN1dGluZyBvbiBob3N0OiBnY2MgIC1mbm8tc3Rh Y2stcHJvdGVjdG9yICAtZmRpYWdub3N0aWNzLWNvbG9yPW5ldmVyIC1JL2RhdGEvdnJpZXMv Z2RiL3NyYy9nZGIvdGVzdHN1aXRlL2xpYiAtYyAtZyAtTzIgIC1vIC9kYXRhL3ZyaWVzL2dk Yi9sZWFwLTE1LTUvYnVpbGQvZ2RiL3Rlc3RzdWl0ZS9vdXRwdXRzL2dkYi5vcHQvaW5saW5l LWVudHJ5L2lubGluZS1lbnRyeTAubyAvZGF0YS92cmllcy9nZGIvc3JjL2dkYi90ZXN0c3Vp dGUvZ2RiLm9wdC9pbmxpbmUtZW50cnkuYyAgICAodGltZW91dCA9IDMwMCkKYnVpbHRpbl9z cGF3biAtaWdub3JlIFNJR0hVUCBnY2MgLWZuby1zdGFjay1wcm90ZWN0b3IgLWZkaWFnbm9z dGljcy1jb2xvcj1uZXZlciAtSS9kYXRhL3ZyaWVzL2dkYi9zcmMvZ2RiL3Rlc3RzdWl0ZS9s aWIgLWMgLWcgLU8yIC1vIC9kYXRhL3ZyaWVzL2dkYi9sZWFwLTE1LTUvYnVpbGQvZ2RiL3Rl c3RzdWl0ZS9vdXRwdXRzL2dkYi5vcHQvaW5saW5lLWVudHJ5L2lubGluZS1lbnRyeTAubyAv ZGF0YS92cmllcy9nZGIvc3JjL2dkYi90ZXN0c3VpdGUvZ2RiLm9wdC9pbmxpbmUtZW50cnku Yw0KZ2RiX2RvX2NhY2hlOiB1bml2ZXJzYWxfY29tcGlsZV9vcHRpb25zX2MgKCAgKQpFeGVj dXRpbmcgb24gaG9zdDogZ2NjICAtZm5vLXN0YWNrLXByb3RlY3RvciAvZGF0YS92cmllcy9n ZGIvbGVhcC0xNS01L2J1aWxkL2dkYi90ZXN0c3VpdGUvb3V0cHV0cy9nZGIub3B0L2lubGlu ZS1lbnRyeS9pbmxpbmUtZW50cnkwLm8gIC1mZGlhZ25vc3RpY3MtY29sb3I9bmV2ZXIgLUkv ZGF0YS92cmllcy9nZGIvc3JjL2dkYi90ZXN0c3VpdGUvbGliIC1nIC1PMiAgLWxtICAgLW8g L2RhdGEvdnJpZXMvZ2RiL2xlYXAtMTUtNS9idWlsZC9nZGIvdGVzdHN1aXRlL291dHB1dHMv Z2RiLm9wdC9pbmxpbmUtZW50cnkvaW5saW5lLWVudHJ5ICAgICh0aW1lb3V0ID0gMzAwKQpi dWlsdGluX3NwYXduIC1pZ25vcmUgU0lHSFVQIGdjYyAtZm5vLXN0YWNrLXByb3RlY3RvciAv ZGF0YS92cmllcy9nZGIvbGVhcC0xNS01L2J1aWxkL2dkYi90ZXN0c3VpdGUvb3V0cHV0cy9n ZGIub3B0L2lubGluZS1lbnRyeS9pbmxpbmUtZW50cnkwLm8gLWZkaWFnbm9zdGljcy1jb2xv cj1uZXZlciAtSS9kYXRhL3ZyaWVzL2dkYi9zcmMvZ2RiL3Rlc3RzdWl0ZS9saWIgLWcgLU8y IC1sbSAtbyAvZGF0YS92cmllcy9nZGIvbGVhcC0xNS01L2J1aWxkL2dkYi90ZXN0c3VpdGUv b3V0cHV0cy9nZGIub3B0L2lubGluZS1lbnRyeS9pbmxpbmUtZW50cnkNCmJ1aWx0aW5fc3Bh d24gL2RhdGEvdnJpZXMvZ2RiL2xlYXAtMTUtNS9idWlsZC9nZGIvdGVzdHN1aXRlLy4uLy4u L2dkYi9nZGIgLW53IC1ueCAtcSAtaWV4IHNldCBoZWlnaHQgMCAtaWV4IHNldCB3aWR0aCAw IC1kYXRhLWRpcmVjdG9yeSAvZGF0YS92cmllcy9nZGIvbGVhcC0xNS01L2J1aWxkL2dkYi9k YXRhLWRpcmVjdG9yeQ0KKGdkYikgc2V0IGhlaWdodCAwDQooZ2RiKSBzZXQgd2lkdGggMA0K KGdkYikgZGlyDQpSZWluaXRpYWxpemUgc291cmNlIHBhdGggdG8gZW1wdHk/ICh5IG9yIG4p IHkNClNvdXJjZSBkaXJlY3RvcmllcyBzZWFyY2hlZDogJGNkaXI6JGN3ZA0KKGdkYikgZGly IC9kYXRhL3ZyaWVzL2dkYi9zcmMvZ2RiL3Rlc3RzdWl0ZS9nZGIub3B0DQpTb3VyY2UgZGly ZWN0b3JpZXMgc2VhcmNoZWQ6IC9kYXRhL3ZyaWVzL2dkYi9zcmMvZ2RiL3Rlc3RzdWl0ZS9n ZGIub3B0OiRjZGlyOiRjd2QNCihnZGIpIGtpbGwNClRoZSBwcm9ncmFtIGlzIG5vdCBiZWlu ZyBydW4uDQooZ2RiKSBmaWxlIC9kYXRhL3ZyaWVzL2dkYi9sZWFwLTE1LTUvYnVpbGQvZ2Ri L3Rlc3RzdWl0ZS9vdXRwdXRzL2dkYi5vcHQvaW5saW5lLWVudHJ5L2lubGluZS1lbnRyeQ0K UmVhZGluZyBzeW1ib2xzIGZyb20gL2RhdGEvdnJpZXMvZ2RiL2xlYXAtMTUtNS9idWlsZC9n ZGIvdGVzdHN1aXRlL291dHB1dHMvZ2RiLm9wdC9pbmxpbmUtZW50cnkvaW5saW5lLWVudHJ5 Li4uDQooZ2RiKSBkZWxldGUgYnJlYWtwb2ludHMNCihnZGIpIGluZm8gYnJlYWtwb2ludHMN Ck5vIGJyZWFrcG9pbnRzLCB3YXRjaHBvaW50cywgdHJhY2Vwb2ludHMsIG9yIGNhdGNocG9p bnRzLg0KKGdkYikgYnJlYWsgLXF1YWxpZmllZCBtYWluDQpCcmVha3BvaW50IDEgYXQgMHg0 MDAzZDA6IGZpbGUgL2RhdGEvdnJpZXMvZ2RiL3NyYy9nZGIvdGVzdHN1aXRlL2dkYi5vcHQv aW5saW5lLWVudHJ5LmMsIGxpbmUgMzguDQooZ2RiKSBydW4gDQpTdGFydGluZyBwcm9ncmFt OiAvZGF0YS92cmllcy9nZGIvbGVhcC0xNS01L2J1aWxkL2dkYi90ZXN0c3VpdGUvb3V0cHV0 cy9nZGIub3B0L2lubGluZS1lbnRyeS9pbmxpbmUtZW50cnkgDQoNCkJyZWFrcG9pbnQgMSwg bWFpbiAoKSBhdCAvZGF0YS92cmllcy9nZGIvc3JjL2dkYi90ZXN0c3VpdGUvZ2RiLm9wdC9p bmxpbmUtZW50cnkuYzozOA0KMzgJICBpZiAoKGdsb2JhbCAmJiBiYXIgKDEpKSB8fCBiYXIg KDIpKQ0KKGdkYikgaW5mbyBzb3VyY2UNCkN1cnJlbnQgc291cmNlIGZpbGUgaXMgL2RhdGEv dnJpZXMvZ2RiL3NyYy9nZGIvdGVzdHN1aXRlL2dkYi5vcHQvaW5saW5lLWVudHJ5LmMNCkNv bXBpbGF0aW9uIGRpcmVjdG9yeSBpcyAvZGF0YS92cmllcy9nZGIvbGVhcC0xNS01L2J1aWxk L2dkYi90ZXN0c3VpdGUNCkxvY2F0ZWQgaW4gL2RhdGEvdnJpZXMvZ2RiL2JpbnV0aWxzLWdk Yi5naXQvZ2RiL3Rlc3RzdWl0ZS9nZGIub3B0L2lubGluZS1lbnRyeS5jDQpDb250YWlucyA0 MSBsaW5lcy4NClNvdXJjZSBsYW5ndWFnZSBpcyBjLg0KUHJvZHVjZXIgaXMgR05VIEMxMSA3 LjUuMCAtbXR1bmU9Z2VuZXJpYyAtbWFyY2g9eDg2LTY0IC1nIC1PMiAtZm5vLXN0YWNrLXBy b3RlY3Rvci4NCkNvbXBpbGVkIHdpdGggRFdBUkYgNCBkZWJ1Z2dpbmcgZm9ybWF0Lg0KRG9l cyBub3QgaW5jbHVkZSBwcmVwcm9jZXNzb3IgbWFjcm8gaW5mby4NCihnZGIpIGJyZWFrIGJh cg0KQnJlYWtwb2ludCAyIGF0IDB4NDAwM2Q4OiBiYXIuICgyIGxvY2F0aW9ucykNCihnZGIp IHByaW50IC9kICRicG51bQ0KJDEgPSAyDQooZ2RiKSBQQVNTOiBnZGIub3B0L2lubGluZS1l bnRyeS5leHA6IGdldCBudW1iZXIgb2YgYmFyIGJyZWFrcG9pbnQKYnJlYWsgZm9vDQpCcmVh a3BvaW50IDMgYXQgMHg0MDA0ZTA6IGZpbGUgL2RhdGEvdnJpZXMvZ2RiL3NyYy9nZGIvdGVz dHN1aXRlL2dkYi5vcHQvaW5saW5lLWVudHJ5LmMsIGxpbmUgMjMuDQooZ2RiKSBwcmludCAv ZCAkYnBudW0NCiQyID0gMw0KKGdkYikgUEFTUzogZ2RiLm9wdC9pbmxpbmUtZW50cnkuZXhw OiBnZXQgbnVtYmVyIG9mIGZvbyBicmVha3BvaW50CmNvbnRpbnVlDQpDb250aW51aW5nLg0K DQpCcmVha3BvaW50IDIuMSwgYmFyICh2YWw9PG9wdGltaXplZCBvdXQ+KSBhdCAvZGF0YS92 cmllcy9nZGIvc3JjL2dkYi90ZXN0c3VpdGUvZ2RiLm9wdC9pbmxpbmUtZW50cnkuYzoyOQ0K MjkJICBpZiAoZ2xvYmFsID09IHZhbCkNCihnZGIpIFBBU1M6IGdkYi5vcHQvaW5saW5lLWVu dHJ5LmV4cDogY29udGludWUgdG8gYmFyCmNvbnRpbnVlDQpDb250aW51aW5nLg0KDQpCcmVh a3BvaW50IDIuMiwgYmFyICh2YWw9MikgYXQgL2RhdGEvdnJpZXMvZ2RiL3NyYy9nZGIvdGVz dHN1aXRlL2dkYi5vcHQvaW5saW5lLWVudHJ5LmM6MjkNCjI5CSAgaWYgKGdsb2JhbCA9PSB2 YWwpDQooZ2RiKSBGQUlMOiBnZGIub3B0L2lubGluZS1lbnRyeS5leHA6IGNvbnRpbnVlIHRv IGZvbwpjb250aW51ZQ0KQ29udGludWluZy4NCg0KQnJlYWtwb2ludCAzLCBmb28gKGFyZz1h cmdAZW50cnk9MSkgYXQgL2RhdGEvdnJpZXMvZ2RiL3NyYy9nZGIvdGVzdHN1aXRlL2dkYi5v cHQvaW5saW5lLWVudHJ5LmM6MjMNCjIzCSAgZ2xvYmFsICs9IGFyZzsNCihnZGIpIEZBSUw6 IGdkYi5vcHQvaW5saW5lLWVudHJ5LmV4cDogY29udGludWUgdW50aWwgZXhpdAp0ZXN0Y2Fz ZSAvZGF0YS92cmllcy9nZGIvc3JjL2dkYi90ZXN0c3VpdGUvZ2RiLm9wdC9pbmxpbmUtZW50 cnkuZXhwIGNvbXBsZXRlZCBpbiAwIHNlY29uZHMKCgkJPT09IGdkYiBTdW1tYXJ5ID09PQoK IyBvZiBleHBlY3RlZCBwYXNzZXMJCTMKIyBvZiB1bmV4cGVjdGVkIGZhaWx1cmVzCTIKRXhl Y3V0aW5nIG9uIGhvc3Q6IC9kYXRhL3ZyaWVzL2dkYi9sZWFwLTE1LTUvYnVpbGQvZ2RiL3Rl c3RzdWl0ZS8uLi8uLi9nZGIvZ2RiIC1udyAtbnggLXEgLWlleCAic2V0IGhlaWdodCAwIiAt aWV4ICJzZXQgd2lkdGggMCIgLWRhdGEtZGlyZWN0b3J5IC9kYXRhL3ZyaWVzL2dkYi9sZWFw LTE1LTUvYnVpbGQvZ2RiL2RhdGEtZGlyZWN0b3J5IC0tdmVyc2lvbiAgICAodGltZW91dCA9 IDMwMCkKYnVpbHRpbl9zcGF3biAtaWdub3JlIFNJR0hVUCAvZGF0YS92cmllcy9nZGIvbGVh cC0xNS01L2J1aWxkL2dkYi90ZXN0c3VpdGUvLi4vLi4vZ2RiL2dkYiAtbncgLW54IC1xIC1p ZXggc2V0IGhlaWdodCAwIC1pZXggc2V0IHdpZHRoIDAgLWRhdGEtZGlyZWN0b3J5IC9kYXRh L3ZyaWVzL2dkYi9sZWFwLTE1LTUvYnVpbGQvZ2RiL2RhdGEtZGlyZWN0b3J5IC0tdmVyc2lv bg0KR05VIGdkYiAoR0RCKSAxNi4wLjUwLjIwMjQxMTE0LWdpdA0KQ29weXJpZ2h0IChDKSAy MDI0IEZyZWUgU29mdHdhcmUgRm91bmRhdGlvbiwgSW5jLg0KTGljZW5zZSBHUEx2Mys6IEdO VSBHUEwgdmVyc2lvbiAzIG9yIGxhdGVyIDxodHRwOi8vZ251Lm9yZy9saWNlbnNlcy9ncGwu aHRtbD4NClRoaXMgaXMgZnJlZSBzb2Z0d2FyZTogeW91IGFyZSBmcmVlIHRvIGNoYW5nZSBh bmQgcmVkaXN0cmlidXRlIGl0Lg0KVGhlcmUgaXMgTk8gV0FSUkFOVFksIHRvIHRoZSBleHRl bnQgcGVybWl0dGVkIGJ5IGxhdy4NCi9kYXRhL3ZyaWVzL2dkYi9sZWFwLTE1LTUvYnVpbGQv Z2RiL2dkYiB2ZXJzaW9uICAxNi4wLjUwLjIwMjQxMTE0LWdpdCAtbncgLW54IC1xIC1pZXgg InNldCBoZWlnaHQgMCIgLWlleCAic2V0IHdpZHRoIDAiIC1kYXRhLWRpcmVjdG9yeSAvZGF0 YS92cmllcy9nZGIvbGVhcC0xNS01L2J1aWxkL2dkYi9kYXRhLWRpcmVjdG9yeSAKCnJ1bnRl c3QgY29tcGxldGVkIGF0IEZyaSBOb3YgMTUgMDk6MDQ6NDYgMjAyNAo= --------------alr5IUei6brI0LvzkmGpuYpK--