From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id jnUkF/r3gmWFyyUAWB0awg (envelope-from ) for ; Wed, 20 Dec 2023 09:19:38 -0500 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=R3a9Deag; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 548CB1E0C3; Wed, 20 Dec 2023 09:19:38 -0500 (EST) Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 45A811E0AC for ; Wed, 20 Dec 2023 09:19:36 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B0AF53861010 for ; Wed, 20 Dec 2023 14:19:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B0AF53861010 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1703081975; bh=Oe8PyYcfkGiNs/DLiCHKDuGqrYGxG4zTKTrZKePp9M8=; h=References:In-Reply-To:Date:Subject:To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=R3a9Deag7RzM8OqSBtY45bqYO7MbDmtMsXtxgCAenQHNd5AQapxhdZrScyKaIoouS xLziTnB0mTgaLxUapJv2rbvmbRhdC3JEAI2zxfTMfUbjpCu9aOYCt51xDDWK9jfYQP MuRVcRJI8lw+ozkboKrQmY0negQOFwLTSlWm9yQ0= Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 1CA9F3858D20 for ; Wed, 20 Dec 2023 14:19:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1CA9F3858D20 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1CA9F3858D20 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703081950; cv=none; b=mOhYlYGFC0NkNGPGr0gOoPzhNWGx91E9fTsNiSgNZLCnCyl6b48fZtDKk+T8z29Ii4sovrYt1qcHPmPe1am6u31jpQsL7GZztOQHQQj85S/Nba1G7xR5ghzvCwZn9+5KtU5EBye7qQmqU6UXMTLf2J6MPn08h/5jD7cEQSed25A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703081950; c=relaxed/simple; bh=mqeCiqoX6gITOT3Fw+ZRaJ+ySiBfPZOFhkZnuZebMTg=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=QWBxKAQa4ZSpO0GPrcqv6Y49vO/PyAFe9yFmJf5ZJR1747E7HQpVoaUgNr3BHqHCUAUmYDQvpDl49AJcAb8L5mezTLSrvtlFZLNk49RmLlOIpJXHp4KsImKGdFH3cKDmRsi2jVrpRezDOnYyNDIwZ4pKKd0pylYB76kcp3efzlI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-55372c1338bso3849591a12.2 for ; Wed, 20 Dec 2023 06:19:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703081948; x=1703686748; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Oe8PyYcfkGiNs/DLiCHKDuGqrYGxG4zTKTrZKePp9M8=; b=n/LMZ2bV7PPBeb2OYVXhEzPnUe+CCDmM+qAdsiRwh+dQcaF9AEh/p83WrKAA2HB3Fx ssKIyNfjIZN3IpTJVSTxASnkyBeE+d5a56ZVMgwqoSpxQP/7/Or7uhMTvFtKCWNNF1hb j49pNLCIkuihGWfvJT8rlvEMJ5Ki+PbZEbLSfTRX5YujobAHM8HteoeNSHNcp56ccUIh LZq4txRVMAv8c2Ns5XhjVUEQJGFQeKChqrPTTTxNa1nhfVaK4pcROHZkxxKEQy1KARto jfCrUkzoIgFbJv+SZiUQs0C/8T6hYEr+pqg9Bmn9prgZpHdmHy5RPkf7RXhRvJBs6rPp qedw== X-Gm-Message-State: AOJu0YwoNf0zaHqMpXLiG74Tiw7OyQeCrTeZOFkMTW62qDGOqJ0ozzqg 2j9/VlYF8sdn5A/iDaGKoyoQP9rMJgCJCbfUKDI= X-Google-Smtp-Source: AGHT+IFPtrwsSjCuP4e6Kpku0+ReD37FCppHbhX3zFR7TyP1y8nm5QybRrt01+EFG1Jeix7LIVvl5PwPWLNX5ehjcI0= X-Received: by 2002:a05:6402:222b:b0:551:3f17:4763 with SMTP id cr11-20020a056402222b00b005513f174763mr7469733edb.80.1703081947471; Wed, 20 Dec 2023 06:19:07 -0800 (PST) MIME-Version: 1.0 References: <874jgp7ksd.fsf@tromey.com> <87plzceio4.fsf@tromey.com> In-Reply-To: <87plzceio4.fsf@tromey.com> Date: Wed, 20 Dec 2023 17:18:55 +0300 Message-ID: Subject: Re: "previous frame inner to this frame" error when unwinding fibers To: Tom Tromey Cc: Andrey Turkin via Gdb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Andrey Turkin via Gdb Reply-To: Andrey Turkin Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" =D0=BF=D0=BD, 11 =D0=B4=D0=B5=D0=BA. 2023=E2=80=AF=D0=B3. =D0=B2 20:46, Tom= Tromey : > > Andrey> One possible solution that comes to my mind is to allow unwinders= to > Andrey> specify the type of the frame (ideally that would be the frame be= ing > Andrey> unwinded, i.e. one from PendingFrame; UnwindInfo I think is all a= bout > Andrey> the next frame though). This would be enough to solve this issue = since > Andrey> the inner-frame checking code only works with normal caller-calle= e > Andrey> pairs. Not sure which type it would be; sigtrap is the one most > Andrey> closely resembling it I think but not quite it. > > SIGTRAMP_FRAME has some special handling in stack.c, so stack traces > would be formatted differently. I guess we could introduce a new > constant if we wanted to go this route. > > Andrey> PS: One other thing that is needed for the fiber/coroutine use ca= se is > Andrey> an ability to perform backtraces from a random starting point. > Andrey> Backtrace through the switch point is what's needed for active > Andrey> asymmetric coroutines like generators and such; however it would = be > Andrey> nice to be able to see the current stack of suspended asymmetric > Andrey> coroutines, or to see the state of symmetric coroutines. > > A while ago I wrote some initial support for "green threads" by > extending the Python API. See this thread: > > https://inbox.sourceware.org/gdb/YiCk+NNtAGQPhyK5@stefanha-x1.localdomain= / > > Your situation sounds somewhat similar -- the basic idea is to model > user-space threads, letting Python code replace the sentinel frame. > Then, unlike with 'select-frame', backtraces will work ok. > > However maybe your case isn't really identical to this. Like, do > coroutines store registers? Maybe some more abstract approach is needed. > > Tom Stackful coroutines I've ever encountered are very close to cooperative green threads - minus an underlying scheduler - in their implementation (separate stack + ucontext to store ABI-saved registers); a mental model is a bit different. I like the idea you proposed in that thread, with a caveat that the green threads would be more ephemeral. E.g. if I want to see the state of a coroutine, I'd spin up a green thread for it, switch to it and do whatever I'd usually do with a thread of execution; and then when I'm done I'd switch over to another thread and wind the green thread down so it is no more (or maybe I'd cache those threads and destroy them in bulk upon debuggee resume). As long as there is a Python API to manage them and as long as their model is similar enough to the OS threads' API, I'm sure we'd be able to code whatever solution suits one's specific needs. Regards, Andrey