From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [81.169.146.162]) by sourceware.org (Postfix) with ESMTPS id 63DAC385782B for ; Mon, 24 May 2021 14:58:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 63DAC385782B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=bruno@clisp.org ARC-Seal: i=1; a=rsa-sha256; t=1621868301; cv=none; d=strato.com; s=strato-dkim-0002; b=aEhD6is9YcYtaHdYKVpipqsaIj4tGwczXcHCkse3wm0S7I/0wD3SS2BFfWw/X6ZZ39 xO622bgjL28fIin8lwjab5mfJSRqmZ6MbVSGzz6bNtFbMnZ9nBMvrasPmZe/FSvBz0DY 7hh6NDG/TosKfztDaNSSBZ9Szmkr2ZBz3l+s2hgUMoDhlJzU6TpN+cejPDRamjTWk8qB YOJGbl8aPXOVyh+TViAtSt4u1keSlHYwF6wj0YwIeAkhl7296KGAzjcRWpEctQ+UO9Xz 1ZXjkSdKZp8QQPDw5oarLQlgtpaiM0hbOHoy91/STeBfV4iuIlFhUiXqtkhRp3B+YLGn gpdw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1621868301; s=strato-dkim-0002; d=strato.com; h=Message-ID:Date:Subject:To:From:Cc:Date:From:Subject:Sender; bh=vMJPNx78jrXhtuUyv4346BQKFNXDWEGpEe58JThZ2nw=; b=td/HhKcziABgCCc3vc31PHTIZYWQgwiaRwUOfFscKVL0Ux/qONFRHuRCS+cy6MZD3W 0KSykOGonKMAort+ny5vHGrDXL4PWTLM4DJkqnOsaxv5iNqNPDfoeyMNHbAk/FhzidXU Hr5c86yQfNRFU8bGUY929G8EfSnEzNmAhnRayYwzAeO7fyLODQmJBYKhCGMavI6H7Dj9 Q8iR17CO2j0JocDAXKVbAvyzywgT7AZLRbfHSOpdR9OiS6FdfanQlc4iGRT6KlU7ydmt CpLSuB2m2ERywl3vPua7KE4T2hw+sw6/Lo/4ZrG1edd+g6drJuOIBjOYHsDbfyJqYJRc S+9g== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1621868301; s=strato-dkim-0002; d=clisp.org; h=Message-ID:Date:Subject:To:From:Cc:Date:From:Subject:Sender; bh=vMJPNx78jrXhtuUyv4346BQKFNXDWEGpEe58JThZ2nw=; b=IISQyJIc0bK37ztrFQG/y6mqegd2a9+8ywQNecdjIFGdnXBUKjYTListmkqqyxP+/c xjQzKVVr8fYGD90fpOqVy4psuJP1ZBEsT6UwTwktbd9GZmcat8fFx5l6cbXlI7YxphGc H7mfPE3WxulKUVojqeUphT9+DohrqCdashF10fgEX7i9Yhu6pqisO3YBTPQmCg46+h4O rGnS7QoKAGa1Ix/5NXo2/3KpvtyFotjeRgy9qhOPs7fFF9r1QbxvPh0Ry2coGnTX2V4k ltbXCsGB3FFtKgHLeMKeQ3J82RszgASIZgGUj96dnsMTkAD9/zhwgP1LFtILiNzsDhbm IrYg== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf3z5NW" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.26.1 DYNA|AUTH) with ESMTPSA id Z0bd4cx4OEwL8ps (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Mon, 24 May 2021 16:58:21 +0200 (CEST) From: Bruno Haible To: Florian Weimer , libc-alpha@sourceware.org Subject: Re: [PATCH 3/3] Misc: Add and the cstack_* family of functions Date: Mon, 24 May 2021 16:58:20 +0200 Message-ID: <73724441.XAIsEQcG03@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-210-generic; KDE/5.18.0; x86_64; ; ) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1621871455.Wf0kUHk1WS" Content-Transfer-Encoding: 7Bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FAKE_REPLY_A1, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 14:58:26 -0000 This is a multi-part message in MIME format. --nextPart1621871455.Wf0kUHk1WS Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" In reply to : > These functions are expected to be used with sigaltstack and > coroutines. What is the added value of these functions, compared to what existing programs already do? I did a small survey of how a couple of single-threaded programs allocate their alternate stack: - The majority allocate it statically. - Some use malloc(). - Some use mmap(). - Some use alloca(), i.e. a portion of the already-allocated stack in the program's main() function. The size that these programs use are: - some use SIGSTKSZ, - some use 16 KiB, - some use 64 KiB. We know that 16 KiB is too small on some platforms, and that a static allocation of SIGSTKSZ bytes leads to a compilation error now. Therefore the implemented added value is: * The ability to use SIGSTKSZ without a compilation error. Other added value that would be useful in some cases are: * The ability to have a guard page at the stack top. This is half implemented. IMO an mprotect (.., top_guard_size, PROT_NONE) is missing after the __mmap call. * The ability to have a guard page at the stack bottom. This too is half implemented. IMO an mprotect (.., bottom_guard_size, PROT_NONE) is missing after the __mmap call. * A verification that the allocated size is not larger than getrlimit(RLIMIT_STACK). If the system or the user has set a maximum stack size of, say, 8 MB, should the program be able to allocate a stack of 1 GB size, in this way? * Support for GCC nested functions, when they need an executable stack. GCC, binutils, and glibc/nptl/allocatestack.c go to great lengths to support this, even from dynamically loaded shared libraries. (See the attached test cases.) It is poor if this facility does not support it. * Automatic deallocation when the current thread exits. In those cases where a thread allocated a cstack_t for its own use, it is welcome if it can say "clean it up automatically when the thread exits". Otherwise some programmers will still prefer the "use alloca()" approach, which has this automatic cleanup property. Bruno --nextPart1621871455.Wf0kUHk1WS Content-Disposition: attachment; filename="nested-functions.tar.gz" Content-Transfer-Encoding: base64 Content-Type: application/x-compressed-tar; name="nested-functions.tar.gz" H4sIAOm9q2AAA+1ZbU/jRhDmc37FNBWn2MRJ7LxYOo5KVa8fKqHqVF17ag8UGXuTbOusrbVNmyL+ e2d37ZAEgo8SQqHzfAA89s7O2vs8M7MIluUsciaFCHOeiKwbsYti2gkPdogeYjQaqN+uP+yt/tYY 9EcH7qA39PzeaDAYHvTcwQhvQ2+XQWxDkeWBBDi4kIVI7nmu7v4LRdeGD5KLHPR3n3IxBS4mSQfA 7jYaX3MRxkXE4F2WRzzpzL5ZN8X8Yt1WCI5mZWtcJjwyXsfKI7SUwWpcNQD0fMV8vjjGi3CG7z9M 5vNARJ/dXu9cGbNUBTWBVnmjDc0wyKGbyiTsHhbdeZBmzTa0CpHxqWCRcmnBlOUpTtqyLO1jgVt7 vnShbZXb5pnA7x7+AWmCBibhBA7TM3Em0OkbHRo+ft147q/z9BCb/DcGd5cKUMf/ft+r+D8cuWh3 h67rEv/3AcX/QObgQjIBpLMM5ALZiFzOZ0i4ImMZmC0B1R4ptUHzO5fBJZMZGwdSBgvDcbBtfdWG VXZCxv9mbdAPtGzly9JP29C1WczmTOR21zL6sDaOHzfQNEkktDjStHcMHN5pb/jX0ZGFN0HHBi09 7Wd+/j/h7i6whf/ePvmPSf+G//2+5r83JP7vAxX/vQfzf60QiNhEJ332FyZTAU+jDSgEa6PCpBD5 WCRCFHE8xockx2jr5rkpQfR4LSlKYfQwXJPU843NzTKMMgilNVdabzjWEKURvjqBH38+PTVCBMbr 0ZGqNq6V383XUMZllrwxn6UjkSwv8CVqy1Mr2Rb+O1w4UexkWJsxXeU9Rg5q+O96fsV/t+95I+S/ 76OJ+L8HIP8/4hfHjXiZYIWNW0AJQbDJebyPxmghgjkPgzheQJIyxSqzQyrluCUNUTwJxa22wXQS a2Jxq1FAJiBHG/MAZ24ZzhpimyQ/PEfiXkEzuAixZFf8wxYBVQgvmjLLSxtca0KtOrduyG7PsC2I GTqKYrUcbAs6XVyJWXsnS9DLTx9P349Pv/3tV90+rIlJy75TgKx6BYITrRVRnC2wPzFRqA7nLndN a8sSbkshLmSLJJaRDNd7oGrQYaH7nkqBULW6dgNsOMUdEcMvgeTBRcyyt8qGzVTKY+aUTdVbaE7D EJxPuCeglAtwJh9++A6cBFbfJSwbC1iWGMdwM3ib7kB5IAFOHMVNFcL3OG1D7bPn5s5rwD36r6i3 kzKwrv7zh+7y/GfY81H/R32f+r+94AH6n88YaDnOZ5IF0fYjojphL2/vopZ72izx35PYTXbepaqV Yn6RWN7D/90Ufwf19V9vtDz/8T3fU/Vf3x8R//eBB9V/NcUeCcCLqbHuKrDWPDmf4rYj0yCftTtU db1e3KP/ZZp/fAVYp/8Dt7/UfywBVf3nux7p/z7wMP1naSCDnG2rANPS/u/6/d1mBfysOQ/LZGDi Gpv/EhgTjkhQAl9Oyrg5GFTz6xSymfnK9z/Oyw+kB6mjyupGiD/x87XemOtqeSuvx5gsc5h5VR5p TqrY8FsyKdVRhXKk/lmMm8WMhkmAOSvCkPVqFMpwXXOtD0OrQH5PVNSrUeymKq406766GJy4DIMS W73+O3/yfPa4s+A6/ff9Sv8xFajzX8/zXKr/94Ldnv9+WZq441D4cZnj2cSejpEpXz1fE7ddoNcO zSnfEQgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKB8MrwD7HvDAEAUAAA --nextPart1621871455.Wf0kUHk1WS--