public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Florian Weimer <fweimer@redhat.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH 3/3] Misc: Add <sys/cstack.h> and the cstack_* family of functions
Date: Mon, 24 May 2021 16:58:20 +0200	[thread overview]
Message-ID: <73724441.XAIsEQcG03@omega> (raw)

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

In reply to <https://sourceware.org/pipermail/libc-alpha/2021-May/126608.html>:

> 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

[-- Attachment #2: nested-functions.tar.gz --]
[-- Type: application/x-compressed-tar, Size: 1302 bytes --]

             reply	other threads:[~2021-05-24 14:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-24 14:58 Bruno Haible [this message]
2021-05-24 15:28 ` Bruno Haible
2021-05-25  7:42   ` Florian Weimer
2021-05-24 19:11 ` Adhemerval Zanella
2021-05-24 23:41   ` Paul Eggert
2021-05-25  7:40     ` Florian Weimer
2021-05-25 12:17       ` Adhemerval Zanella
2021-05-25 12:23         ` Florian Weimer
2021-05-25 12:25           ` Adhemerval Zanella
2021-05-25 12:29     ` Adhemerval Zanella
2021-05-25  8:41 ` Florian Weimer
  -- strict thread matches above, loose matches on Subject: below --
2021-05-20 12:11 [PATCH 0/3] Convenience function for allocating (alternate signal) stacks Florian Weimer
2021-05-20 12:13 ` [PATCH 3/3] Misc: Add <sys/cstack.h> and the cstack_* family of functions Florian Weimer
2021-05-20 12:21   ` Florian Weimer
2021-05-20 12:50   ` Andreas Schwab
2021-05-20 13:14     ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=73724441.XAIsEQcG03@omega \
    --to=bruno@clisp.org \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).