From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id OiBVLDpXn1/1fQAAWB0awg (envelope-from ) for ; Sun, 01 Nov 2020 19:47:54 -0500 Received: by simark.ca (Postfix, from userid 112) id A988E1F08B; Sun, 1 Nov 2020 19:47:54 -0500 (EST) 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 E71A41E590 for ; Sun, 1 Nov 2020 19:47:53 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 86D873857C6C; Mon, 2 Nov 2020 00:47:53 +0000 (GMT) Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 1CA8E3857C6C for ; Mon, 2 Nov 2020 00:47:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1CA8E3857C6C 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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 9C2D71E590; Sun, 1 Nov 2020 19:47:50 -0500 (EST) Subject: Re: [PATCH] Limit the switch_to_thread() calls in startup_inferior() To: Samuel Thibault References: <20201014084940.1289-1-n54@gmx.com> <1b79497d-a376-0c48-9544-ef1bb3056fc9@simark.ca> <20201101183350.4kjanzjzuo7tmumz@function> From: Simon Marchi Message-ID: Date: Sun, 1 Nov 2020 19:47:50 -0500 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: <20201101183350.4kjanzjzuo7tmumz@function> 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: , Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2020-11-01 1:33 p.m., Samuel Thibault wrote: > Hello, > > (Note that I have never really hacked very much into gdb's inferior > management, so I don't know much how things are supposed to be working.) > > Simon Marchi, le sam. 24 oct. 2020 22:58:05 -0400, a ecrit: >> 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. >> > [...] >> 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? > > I am not really sure what I am supposed to test. I tried a program that > starts a second thread which just pause()s. With Kamil's patch I can > switch & backtrace between the two threads. Just testing a "run" would have been sufficient, but you've tested even more, which doesn't hurt. > > (gdb) r > Starting program: /home/samy/test > ^C[New Thread 13012.6] > [New Thread 13012.7] > > Thread 5 received signal SIGINT, Interrupt. > 0x0107951c in ?? () from /lib/i386-gnu/libc.so.0.3 > (gdb) info thread > Id Target Id Frame > * 5 Thread 13012.5 0x0107951c in ?? () from /lib/i386-gnu/libc.so.0.3 > 6 Thread 13012.6 0x0109dc74 in _hurd_intr_rpc_mach_msg () > from /lib/i386-gnu/libc.so.0.3 > 7 Thread 13012.7 0x0107951c in ?? () from /lib/i386-gnu/libc.so.0.3 > (gdb) bt > #0 0x0107951c in ?? () from /lib/i386-gnu/libc.so.0.3 > #1 0x01079cc6 in mach_msg () from /lib/i386-gnu/libc.so.0.3 > [...] > #5 0x0104cdca in pthread_join () from /lib/i386-gnu/libpthread.so.0.3 > #6 0x0803254b in main () at test.c:13 > (gdb) thread 7 > [Switching to thread 7 (Thread 13012.7)] > #0 0x0107951c in ?? () from /lib/i386-gnu/libc.so.0.3 > (gdb) bt > #0 0x0107951c in ?? () from /lib/i386-gnu/libc.so.0.3 > [...] > #3 0x0114e4ce in pause () from /lib/i386-gnu/libc.so.0.3 > #4 0x080324fa in f (foo=0x0) at test.c:6 > #5 0x0104c3ff in entry_point () from /lib/i386-gnu/libpthread.so.0.3 > #6 0x00000000 in ?? () Ok, so it all seems good. >> And what if you remove all the switch_to_thread from that function, does >> it still work? > > If I remove all calls from that fonction I am getting > > (gdb) r > Starting program: /home/samy/test > Can't fetch registers from thread bogus thread id 1: No such thread > (gdb) info thread > Id Target Id Frame > 5 Thread 18821.5 0x000021e0 in ?? () > The current thread has terminated. See `help thread'. Ok, so if we remove these switch_to_thread calls, we get back to the initial problem reported in https://sourceware.org/legacy-ml/gdb/2008-10/msg00034.html So we know they are still necessary, thanks for your help. > Since I now have a built tree I can easily experiment more. I think we have all we need for now, thanks! Simon