From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id W6IVItjplF9oUwAAWB0awg (envelope-from ) for ; Sat, 24 Oct 2020 22:58:32 -0400 Received: by simark.ca (Postfix, from userid 112) id 7D4191F08E; Sat, 24 Oct 2020 22:58:30 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 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 7356C1F086 for ; Sat, 24 Oct 2020 22:58:16 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 912033854812; Sun, 25 Oct 2020 02:58:15 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id B58F63854812 for ; Sun, 25 Oct 2020 02:58:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B58F63854812 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.11] (173-246-6-90.qc.cable.ebox.net [173.246.6.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 1C25E1E99A; Sat, 24 Oct 2020 22:58:09 -0400 (EDT) Subject: Re: [PATCH] Limit the switch_to_thread() calls in startup_inferior() To: Kamil Rytarowski , gdb-patches@sourceware.org, Samuel Thibault References: <20201014084940.1289-1-n54@gmx.com> From: Simon Marchi Message-ID: <1b79497d-a376-0c48-9544-ef1bb3056fc9@simark.ca> Date: Sat, 24 Oct 2020 22:58:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <20201014084940.1289-1-n54@gmx.com> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 7bit 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: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-10-14 4:49 a.m., Kamil Rytarowski wrote: > Do not jump over the threads during the startup unless we encounter > TARGET_WAITKIND_STOPPED with SIGTRAP or TARGET_WAITKIND_EXECD. > > Otherwise whenever a startup-with-shell processes signals on the > startup stage, it might indicate to switch to a non-existing > thread or a special-thread number (target lwp=0 on NetBSD means > that a signal was directed to all threads within a process). > > This caused a crash with tcsh on NetBSD, where the tcsh shell > runs startup detection of the hostname. This action involves > spwaning a new process through fork. > > GDB crashes this way: > $ SHELL=tcsh /usr/bin/gdb echo > (gdb) r > Starting program: /bin/echo > /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/thread.c:1309: internal-error: void switch_to_thread(thread_info*): Assertion `thr != NULL' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > > And the core-dump is as follows: > > (top-gdb) bt > During symbol reading: incomplete CFI data; unspecified registers (e.g., rax) at 0x7f7ff5b698a4 > file=0x135314f "../../gdb/thread.c", line=1309, fmt=0x1353069 "%s: Assertion `%s' failed.", ap=0x7f7fffffdc08) at ../../gdb/utils.c:414 > at ../../gdb/inf-ptrace.c:117 > args=0x0, from_tty=1, run_how=RUN_NORMAL) at ../../gdb/infcmd.c:493 > --Type for more, q to quit, c to continue without paging-- I tried to wrap my head around this and understand the need for the switch_to_thread, what could be the impacts of your change, and I just can't give anything close to a definitive answer. I did a bit of archeology, and found that the switch_to_thread were added by this patch: https://sourceware.org/pipermail/gdb-patches/2008-October/060950.html Following this thread: https://sourceware.org/legacy-ml/gdb/2008-10/msg00034.html Sooo... it sounds like the tid in the ptid made by gnu-nat.c is a bogus integer (looks like it still is today, but it's in lwp instead of tid). And the problem was because the tid increased at every exec. So my theory is that these switch_to_thread were needed to keep the inferior_ptid global sync'ed with the ptid gnu-nat.c knows about. The failure reported in the thread above is this one: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/i386gnu-nat.c;h=3d71047eab7dd4184dd978bb7b351661f09beec5;hb=2e979b9404414113dc61b32eebcda8a53632605c#l124 You can see that back then, gnu_fetch_registers relied on inferior_ptid, so it would make sense for this function to fail if inferior_ptid is stale. I just don't know where/when during the startup_inferior function did gnu_fetch_registers get called (it would have been useful to have a backtrace for that). Today, i386_gnu_nat_target::fetch_registers relies on the ptid of the regcache, not inferior_ptid. Perhaps it's not necessary to call switch_to_thread at all today? It's hard to say. Samuel, as the last person who touched gnu-nat.c, do you have a bit of time to test Kamil's patch on Hurd, see if it breaks starting inferiors? And what if you remove all the switch_to_thread from that function, does it still work? Simon