From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qJgJOD9h6mJExx8AWB0awg (envelope-from ) for ; Wed, 03 Aug 2022 07:51:27 -0400 Received: by simark.ca (Postfix, from userid 112) id E1FF41EA05; Wed, 3 Aug 2022 07:51:27 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=vE3WkNkK; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5C4181E9ED for ; Wed, 3 Aug 2022 07:51:27 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DDF283857C4A for ; Wed, 3 Aug 2022 11:51:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DDF283857C4A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659527486; bh=DAFk8/I4D9LGIE56Tsl3gxVmqAQWnrmHXP+HDpT7s/M=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=vE3WkNkKmmeaLZv02R81DIJzzi2AXV80YGCNtEIhLWP55SrAjO/hhO1Ydk5mk4EJn BztogUd5GXm2TunSqij6GcoJxe34xNzCQu787kEHnfMH3nnk2QUM/eRwgWsp9im500 WAbcnwZTEKuaX0dHDX3mNkeJf2XSfXbVZJnfqiAM= Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id AE9EA3858CDB for ; Wed, 3 Aug 2022 11:51:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AE9EA3858CDB Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id EBEA24D2CF; Wed, 3 Aug 2022 11:51:05 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C677313A94; Wed, 3 Aug 2022 11:51:05 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id ZZhZLylh6mLUTQAAMHmgww (envelope-from ); Wed, 03 Aug 2022 11:51:05 +0000 Content-Type: multipart/mixed; boundary="------------SJXV2xZ0MdaKTYFM7CLTpSit" Message-ID: <88befc1b-1288-16d0-f3d2-20a8af4cf616@suse.de> Date: Wed, 3 Aug 2022 13:51:05 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH 2/2] gdb/testsuite: Accept PIE/noPIE programs in gdb.mi/mi-var-invalidate-shlib.exp Content-Language: en-US To: "Six, Lancelot" , "gdb-patches@sourceware.org" References: <20220802124724.284096-1-lancelot.six@amd.com> <20220802124724.284096-3-lancelot.six@amd.com> In-Reply-To: X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Cc: "lsix@lancelotsix.com" Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" This is a multi-part message in MIME format. --------------SJXV2xZ0MdaKTYFM7CLTpSit Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/3/22 11:35, Six, Lancelot wrote: > [AMD Official Use Only - General] > >> Hi, >> >> thanks for the analysis. >> >> After looking into this a bit, I wonder if the root cause is really >> looking at the values in the old process. >> >> Maybe we should either: >> - not try to sample the values when recreating, or >> - move the recreation to a later point when we have access to the memory >> of the new process. >> >> At least we would have consistency between PIE and no-PIE with either >> solution. >> >> Thanks, >> - Tom > > Hi, > > I do agree that it is strange to look for a value for the new objfile in the old process. I wonder if there are legitimate usecases where one would want to still use "file ..." to load new symbols but keep the same process running while keeping a global varobj around. If we delay the recreation of the varobj, we would break such usecase. > You're right, apparently that's a valid use case. > One way could be to be just invalidate the varobj when the objfile it relies on goes away and give the user a "-var-reinflate" command (or "-var-update -reinflate") so he can try to revive an invalidated varobj at his convenience. This would break existing behavior but could avoid. I've now reached the conclusion that the bug is merely that for recreating the varobjs we don't wait until relocation has happened, as we do for breakpoints. This WIP patch delays recreation of the varobj to the point that the file command has relocated the PIE exec. This makes behaviour equal between PIE and no-PIE (meaning we see the same two FAILs now for gdb.mi/mi-var-invalidate-shlib.exp). I'm not sure about the split between invalidate and re_set, I'm not familiar with this code. WDYT? Thanks, - Tom --------------SJXV2xZ0MdaKTYFM7CLTpSit Content-Type: text/x-patch; charset=UTF-8; name="tmp.patch" Content-Disposition: attachment; filename="tmp.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2dkYi9zeW1maWxlLmMgYi9nZGIvc3ltZmlsZS5jCmluZGV4IGFlYThj NzYyZWU2Li5kMGEzMmQxMzIzMSAxMDA2NDQKLS0tIGEvZ2RiL3N5bWZpbGUuYworKysgYi9n ZGIvc3ltZmlsZS5jCkBAIC0xNjU2LDYgKzE2NTYsOSBAQCBzeW1ib2xfZmlsZV9jb21tYW5k IChjb25zdCBjaGFyICphcmdzLCBpbnQgZnJvbV90dHkpCiAKICAgICAgIC8qIE5vdyBpdCdz IHNhZmUgdG8gcmUtYWRkIHRoZSBicmVha3BvaW50cy4gICovCiAgICAgICBicmVha3BvaW50 X3JlX3NldCAoKTsKKworICAgICAgLyogQWxzbywgaXQncyBzYWZlIHRvIHJlLWFkZCB2YXJv YmpzLiAgKi8KKyAgICAgIHZhcm9ial9yZV9zZXQgKCk7CiAgICAgfQogfQogCmRpZmYgLS1n aXQgYS9nZGIvdmFyb2JqLmMgYi9nZGIvdmFyb2JqLmMKaW5kZXggMDY4M2FmMTk5MWUuLmVj YzUzZjI2NDNkIDEwMDY0NAotLS0gYS9nZGIvdmFyb2JqLmMKKysrIGIvZ2RiL3Zhcm9iai5j CkBAIC0yMzYyLDYgKzIzNjIsMjYgQEAgYWxsX3Jvb3RfdmFyb2JqcyAoZ2RiOjpmdW5jdGlv bl92aWV3PHZvaWQgKHN0cnVjdCB2YXJvYmogKnZhcik+IGZ1bmMpCiAKIHN0YXRpYyB2b2lk CiB2YXJvYmpfaW52YWxpZGF0ZV9pdGVyIChzdHJ1Y3QgdmFyb2JqICp2YXIpCit7CisgIC8q IGdsb2JhbCBhbmQgZmxvYXRpbmcgdmFyIG11c3QgYmUgcmUtZXZhbHVhdGVkLiAgKi8KKyAg aWYgKHZhci0+cm9vdC0+ZmxvYXRpbmcgfHwgdmFyLT5yb290LT5nbG9iYWwpCisgICAgOwor ICBlbHNlIC8qIGxvY2FscyBtdXN0IGJlIGludmFsaWRhdGVkLiAgKi8KKyAgICB2YXItPnJv b3QtPmlzX3ZhbGlkID0gZmFsc2U7Cit9CisKKy8qIEludmFsaWRhdGUgdGhlIHZhcm9ianMg dGhhdCBhcmUgdGllZCB0byBsb2NhbHMgYW5kIHJlLWNyZWF0ZSB0aGUgb25lcyB0aGF0Cisg ICBhcmUgZGVmaW5lZCBvbiBnbG9iYWxzLgorICAgSW52YWxpZGF0ZWQgdmFyb2JqcyB3aWxs IGJlIGFsd2F5cyBwcmludGVkIGluX3Njb3BlPSJpbnZhbGlkIi4gICovCisKK3ZvaWQKK3Zh cm9ial9pbnZhbGlkYXRlICh2b2lkKQoreworICBhbGxfcm9vdF92YXJvYmpzICh2YXJvYmpf aW52YWxpZGF0ZV9pdGVyKTsKK30KKworc3RhdGljIHZvaWQKK3Zhcm9ial9yZV9zZXRfaXRl ciAoc3RydWN0IHZhcm9iaiAqdmFyKQogewogICAvKiBnbG9iYWwgYW5kIGZsb2F0aW5nIHZh ciBtdXN0IGJlIHJlLWV2YWx1YXRlZC4gICovCiAgIGlmICh2YXItPnJvb3QtPmZsb2F0aW5n IHx8IHZhci0+cm9vdC0+Z2xvYmFsKQpAQCAtMjM4NywxOCArMjQwNywxMiBAQCB2YXJvYmpf aW52YWxpZGF0ZV9pdGVyIChzdHJ1Y3QgdmFyb2JqICp2YXIpCiAJICB2YXItPnJvb3QtPmlz X3ZhbGlkID0gZmFsc2U7CiAJfQogICAgIH0KLSAgZWxzZSAvKiBsb2NhbHMgbXVzdCBiZSBp bnZhbGlkYXRlZC4gICovCi0gICAgdmFyLT5yb290LT5pc192YWxpZCA9IGZhbHNlOwogfQog Ci0vKiBJbnZhbGlkYXRlIHRoZSB2YXJvYmpzIHRoYXQgYXJlIHRpZWQgdG8gbG9jYWxzIGFu ZCByZS1jcmVhdGUgdGhlIG9uZXMgdGhhdAotICAgYXJlIGRlZmluZWQgb24gZ2xvYmFscy4K LSAgIEludmFsaWRhdGVkIHZhcm9ianMgd2lsbCBiZSBhbHdheXMgcHJpbnRlZCBpbl9zY29w ZT0iaW52YWxpZCIuICAqLwotCiB2b2lkIAotdmFyb2JqX2ludmFsaWRhdGUgKHZvaWQpCit2 YXJvYmpfcmVfc2V0ICh2b2lkKQogewotICBhbGxfcm9vdF92YXJvYmpzICh2YXJvYmpfaW52 YWxpZGF0ZV9pdGVyKTsKKyAgYWxsX3Jvb3RfdmFyb2JqcyAodmFyb2JqX3JlX3NldF9pdGVy KTsKIH0KIAogLyogRW5zdXJlIHRoYXQgbm8gdmFyb2JqIGtlZXAgcmVmZXJlbmNlcyB0byBP QkpGSUxFLiAgKi8KZGlmZiAtLWdpdCBhL2dkYi92YXJvYmouaCBiL2dkYi92YXJvYmouaApp bmRleCAwNzNkYTYwZDc3Mi4uZjNjY2U4ZWJmYmQgMTAwNjQ0Ci0tLSBhL2dkYi92YXJvYmou aAorKysgYi9nZGIvdmFyb2JqLmgKQEAgLTMxNiw2ICszMTYsOCBAQCBleHRlcm4gc3RkOjp2 ZWN0b3I8dmFyb2JqX3VwZGF0ZV9yZXN1bHQ+CiAKIGV4dGVybiB2b2lkIHZhcm9ial9pbnZh bGlkYXRlICh2b2lkKTsKIAorZXh0ZXJuIHZvaWQgdmFyb2JqX3JlX3NldCAodm9pZCk7CisK IGV4dGVybiBib29sIHZhcm9ial9lZGl0YWJsZV9wIChjb25zdCBzdHJ1Y3QgdmFyb2JqICp2 YXIpOwogCiBleHRlcm4gYm9vbCB2YXJvYmpfZmxvYXRpbmdfcCAoY29uc3Qgc3RydWN0IHZh cm9iaiAqdmFyKTsK --------------SJXV2xZ0MdaKTYFM7CLTpSit--