public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Nilay Vaish via Libc-alpha <libc-alpha@sourceware.org>
Cc: Nilay Vaish <nilayvaish@google.com>,  David Finkelstein <dxf@google.com>
Subject: Re: [PATCH origin/google/grte/v5-2.27/master] nptl: use mmap and munmap for stack allocation
Date: Wed, 26 Oct 2022 09:36:37 +0200	[thread overview]
Message-ID: <87tu3rujcq.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAJm2bjoXyA4Ytc0q9myvd3wStgH9LL96vNg8GTD5_hRK+psKhQ@mail.gmail.com> (Nilay Vaish via Libc-alpha's message of "Tue, 25 Oct 2022 17:17:07 -0700")

* Nilay Vaish via Libc-alpha:

> We made this change so that we can capture thread stack allocations.
> __mmap and __munmap cannot be overridden at runtime.  mmap and munmap
> can be overidden at runtime and we are thus able to capture when either
> of these functions were called.

Not sure if you are proposing this for general discussion?

This will need localplt.data updates on all architectures to avoid
check-localplt failures.  It also introduces a linknamespace issue with
C11 thread support: technically, an application using C11 threads could
define mmap or munmap symbols for arbitrary use (and different behavior)
because those names are not reserved in C11.

If this is intended to become a supported interface, perhaps we should
document it in the manual.  On the other hand, I do not see how this
could work in general, especially not with static linking.  glibc may
have to call mmap in certain places where the process or thread is not
fully initialized.

Thanks,
Florian


  reply	other threads:[~2022-10-26  7:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-26  0:17 Nilay Vaish
2022-10-26  7:36 ` Florian Weimer [this message]
2022-10-27 22:38   ` Nilay Vaish

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=87tu3rujcq.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=dxf@google.com \
    --cc=libc-alpha@sourceware.org \
    --cc=nilayvaish@google.com \
    /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).