From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward107p.mail.yandex.net (forward107p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:115]) by sourceware.org (Postfix) with ESMTPS id 35087385829B for ; Sun, 19 Jun 2022 11:37:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 35087385829B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=yandex.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=yandex.ru Received: from sas1-8501f683a096.qloud-c.yandex.net (sas1-8501f683a096.qloud-c.yandex.net [IPv6:2a02:6b8:c08:78a5:0:640:8501:f683]) by forward107p.mail.yandex.net (Yandex) with ESMTP id 3CDCD556FECE for ; Sun, 19 Jun 2022 14:37:24 +0300 (MSK) Received: from sas1-1f4a002bb12a.qloud-c.yandex.net (sas1-1f4a002bb12a.qloud-c.yandex.net [2a02:6b8:c14:3908:0:640:1f4a:2b]) by sas1-8501f683a096.qloud-c.yandex.net (mxback/Yandex) with ESMTP id MGKHyhcjU6-bNfqZFbs; Sun, 19 Jun 2022 14:37:24 +0300 X-Yandex-Fwd: 2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1655638644; bh=bDddRrkI0naToFiKYZsUGD0llsxgqE8p8Iqt+RvozbU=; h=From:To:Subject:Date:Message-ID; b=CSgHZuk8xm0uJSktdoOYhlTfLH/ZBeSIYILq1/UWwqYjKs9SMBkbl2MYFnhHO9V4B qTq9EQpCT4zoStHAQe5fzCGOxWFeUZAajzGKxk60ZTi22vrQbjmalFtY5nRniX1kS8 vcEKIVG1/gX6fHOt35l2SYGFfqp8T77s6goxe//k= Authentication-Results: sas1-8501f683a096.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Received: by sas1-1f4a002bb12a.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 2jgx7mmVqu-bNruWKIc; Sun, 19 Jun 2022 14:37:23 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Message-ID: Date: Sun, 19 Jun 2022 14:37:23 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: gcc@gcc.gnu.org From: stsp Subject: save/relocate/restore call stack or coroutine? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, 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: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2022 11:37:29 -0000 Hi! Purely theoretical question here. :) Many people, including myself, keep falling into this trap: https://www.reddit.com/r/cpp/comments/eewqwc/serializable_coroutines_in_c_gameplay_code/ Which is that they take the fibers/coroutines to implement some logic with wait/blocking capability, and, because there is a state object (eg ucontext_t) and an explicitly allocated stack frame, they expect to be able to save/restore it along with any other save data. I believe this even worked in some limited scenarios in pre-ASLR era, but today they face the fact that the call stack needs to be somehow "relocated" to be loaded on a different process. I looked around to see what gcc technologines are available to help with that, and what I've found, is: - backtrace() can be used to identify all return addresses on stack, and to patch them up. - Named address spaces __seg_fs, __seg_gs can be used to make some pointers relocation- friendly. Unfortunately there seem to be no way to build the entire compilation unit with __seg_fs being a default address space, and also there seem to be no conversion between __seg_fs and normal pointers (by adding/subtracting rdfsbase on a conversion). - Stack maps: https://www.mail-archive.com/gcc@gcc.gnu.org/msg77319.html were considered too difficult to implement: https://www.mail-archive.com/gcc@gcc.gnu.org/msg77317.html and AFAICS are still not implemented. They could help to identify all pointers to heap objects and relocate them, but I wonder if they are only considered for strongly-typed languages, and not for C/C++. So the question is: how realistic is to expect that the call stacks would be saveable/relocatable one day? How far are we from that point? It looks like all the needed technologies already either exist or at least are considered for an implementation. Or am I missing much more unsolvable problems? Or maybe there is already some other way of doing that? :)