From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 1F88E3858C5F for ; Thu, 9 Nov 2023 15:09:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1F88E3858C5F 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 1F88E3858C5F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:67c:2178:6::1d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699542559; cv=none; b=VVEcig/LTheNnSncW4sb4cD9IWCT39aXAxMzxklm9YDtrMdttPv9xFghbrYMJPfsyOD3GxtU4vBDOHpb+C1YkDhBg8uQuy4hA+S1TB/H2RcsEfpzSAZc1zHgz1yZuFsajnOc9S7OTLtQ5PATpDm7sN87O+WVnfMWj5v3u2oI0i0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699542559; c=relaxed/simple; bh=sJwL6MY3GqY2kpzQCUqFIIA9Te4kE88a8MZHOWzfCnE=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=Mj3wi97RhvHWgj1mMVGNIKPWTZdS4EZO9o+rVUUG9pXvK5QsQ67UqR0ZSUYgZjtfVwSROjbFVB27KPCKYIVCLZFf+7PLBVOrlwTWlXZFIQYpi3IkBtF9bV6EJDnSrW9U966EZqrZoL1XTYHKcIHRbeWUWKeJ8fmgSOQ9rhuCEE4= ARC-Authentication-Results: i=1; server2.sourceware.org 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-out2.suse.de (Postfix) with ESMTPS id DE05B1F8B3; Thu, 9 Nov 2023 15:09:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1699542556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+VjatuPXPq5ZdMl0VBdFMCRQZrZcnb5ipn+tu+1Gz8c=; b=RIhKyYQVYYvuzB1uxY8/FaDsv1imP+HGm3ShDeskc10n7gUMpSYP+KfKJ1voBADs8iJU11 07eJJ62rmmNUCiZthsA4V1l4a65j3zOH9c/oX6mvpGjRjiLV4JDxQ56MmWNvMJIbcszSve azgx9tJvUGxZBWvnRs7QfZQ8u9dDqTI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1699542556; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+VjatuPXPq5ZdMl0VBdFMCRQZrZcnb5ipn+tu+1Gz8c=; b=XQx462lon+PrPq98r9rlqqMJKb4qTiYHr5QtEv45p1IHB5UIqfB118LSpNjtHnEeCgedDZ slPsqNQ+9YFDlYBA== 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 BD2AB13524; Thu, 9 Nov 2023 15:09:16 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 2uX7LBz2TGXuAgAAMHmgww (envelope-from ); Thu, 09 Nov 2023 15:09:16 +0000 Message-ID: <32783e3d-9711-4c20-adfc-6b143da28dcd@suse.de> Date: Thu, 9 Nov 2023 16:10:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/2] [gdb] Fix segfault in for_each_block, part 2 Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20231107131950.3083-1-tdevries@suse.de> <20231107131950.3083-3-tdevries@suse.de> From: Tom de Vries In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On 11/7/23 16:26, Simon Marchi wrote: > On 11/7/23 08:19, Tom de Vries wrote: >> The previous commit describes PR gdb/30547, a segfault when running test-case >> gdb.base/vfork-follow-parent.exp on powerpc64 (likewise on s390x). >> >> The root cause for the segmentation fault is that linux_is_uclinux gives an >> incorrect result: it returns true instead of false. >> >> So, why does linux_is_uclinux: >> ... >> int >> linux_is_uclinux (void) >> { >> CORE_ADDR dummy; >> >> return (target_auxv_search (AT_NULL, &dummy) > 0 >> && target_auxv_search (AT_PAGESZ, &dummy) == 0); >> ... >> return true? >> >> This is because ppc_linux_target_wordsize returns 4 instead of 8, causing >> ppc_linux_nat_target::auxv_parse to misinterpret the auxv vector. >> >> So, why does ppc_linux_target_wordsize: >> ... >> int >> ppc_linux_target_wordsize (int tid) >> { >> int wordsize = 4; >> >> /* Check for 64-bit inferior process. This is the case when the host is >> 64-bit, and in addition the top bit of the MSR register is set. */ >> long msr; >> >> errno = 0; >> msr = (long) ptrace (PTRACE_PEEKUSER, tid, PT_MSR * 8, 0); >> if (errno == 0 && ppc64_64bit_inferior_p (msr)) >> wordsize = 8; >> >> return wordsize; >> } >> ... >> return 4? >> >> Specifically, we get this result because because tid == 0, so we get >> errno == ESRCH. > > I would suggest adding some assertion: > > - assert that inferior_ptid != null_ptid in > ppc_linux_nat_target::auxv_parse and > s390_linux_nat_target::auxv_parse > - assert that tid != 0 in ppc_linux_target_wordsize (and in > s390_target_wordsize), though it could use a bit of refactoring to > take tid as a parameter like ppc_linux_target_wordsize) > I've added these, though I haven't been able to test on s390. >> The tid == 0 is caused by the switch_to_no_thread in >> handle_vfork_child_exec_or_exit: >> ... >> /* Switch to no-thread while running clone_program_space, so >> that clone_program_space doesn't want to read the >> selected frame of a dead process. */ >> scoped_restore_current_thread restore_thread; >> switch_to_no_thread (); >> >> inf->pspace = new program_space (maybe_new_address_space ()); >> ... >> but moving the maybe_new_address_space call to before that gives us the >> same result. The tid is no longer 0, but we still get ESRCH because the >> thread has exited. >> >> Fix this in handle_vfork_child_exec_or_exit by doing the >> maybe_new_address_space call in the context of the vfork parent. >> >> Tested on top of trunk on x86_64-linux and ppc64le-linux. >> Tested on top of gdb-14-branch on ppc64-linux. >> >> PR gdb/30547 >> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30547 >> --- >> gdb/infrun.c | 12 +++++++++++- >> 1 file changed, 11 insertions(+), 1 deletion(-) >> >> diff --git a/gdb/infrun.c b/gdb/infrun.c >> index f0f35c23c9c..94a0924653f 100644 >> --- a/gdb/infrun.c >> +++ b/gdb/infrun.c >> @@ -1105,13 +1105,23 @@ handle_vfork_child_exec_or_exit (int exec) >> go ahead and create a new one for this exiting >> inferior. */ >> >> + std::shared_ptr aspace; >> + { >> + /* Temporarily switch to the vfork parent, to facilitate ptrace >> + calls done during maybe_new_address_space. */ >> + scoped_restore save_inferior_ptid >> + = make_scoped_restore (&inferior_ptid); >> + inferior_ptid = ptid_t (vfork_parent->pid); >> + aspace = maybe_new_address_space (); >> + } > > I guess that's fine as a minimal patch, but it scares me when we just > set part of the global state and inferior_ptid / current_inferior / > current_program_space don't match. maybe_new_address_space calls > gdbarch_has_shared_address_space, which calls linux_is_uclinux, which > reads auxv. auxv can be read in different ways. It's hard to get > convinced that only setting inferior_ptid is enough. > > Since we need a scoped_restore_current_thread in the current scope, can > you move it a bit higher? Something like (untested): > > scoped_restore_current_thread restore_thread; > > /* Temporarily switch to the vfork parent, to facilitate ptrace > calls done during maybe_new_address_space. */ > switch_to_thread (any_live_thread_of_inferior (vfork_parent)); > std::shared_ptr aspace = maybe_new_address_space (); > > /* Switch back to the vfork child inferior. Switch to no-thread while > running clone_program_space, so that clone_program_space doesn't > want to read the selected frame of a dead process. */ > switch_to_inferior_no_thread (inf); > > Below, you can std::move the aspace when creating the new program_space: > > inf->pspace = new program_space (std::move (aspace)); > Done, v3 available here ( https://sourceware.org/pipermail/gdb-patches/2023-November/203933.html ). Thanks, - Tom > Even better, I think, would be to pass the vfork parent inferior as a > new `existing_inferior` parameter to maybe_new_address_space, and pass > it all the way through linux_is_uclinux (and do some inferior switching > there in order to do the target calls). The existing_inferior parameter > would be an inferior that maybe_new_address_space can inspect to > determine if a new address space is needed, and from which it can get > an existing address space, if it determines that the address space > should be shared between the existing and the new inferior. But I think > it's something that can be done later, switching to the parent here is > fine to keep the patch small and easily backportable. > > Simon