From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.3 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 774B91F8C6 for ; Thu, 12 Aug 2021 08:37:08 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B37D9383540F for ; Thu, 12 Aug 2021 08:37:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B37D9383540F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1628757427; bh=23pDxTXNb6BiJVnnbI70LmflE68RamaarpdYtKBlTmM=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=YT0gnKnSAntDMSGltiNC5n4vpG3ZH8gZsPqownM8ryga8ZWg+T19iVnmqEijNxrxQ JpZZ7kUGJ9pvzRnYy+IzyMpt/ata9O4uQyWOU4Vv/zqQNT8qH//NnWNRCNp25d0wJH FCxgWQ6BfVe65gzCWHRs3+pdewkxCKSWNvUEZlEo= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 7394C3835424 for ; Thu, 12 Aug 2021 08:36:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7394C3835424 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-212-024McJnPO6ONx9-HUMvePw-1; Thu, 12 Aug 2021 04:36:35 -0400 X-MC-Unique: 024McJnPO6ONx9-HUMvePw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5BD7D8799EB; Thu, 12 Aug 2021 08:36:34 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5BCF360C9D; Thu, 12 Aug 2021 08:36:32 +0000 (UTC) To: "H.J. Lu" Subject: Re: [PATCH v5 1/1] : An API for tagged address References: <20210805131358.300475-1-hjl.tools@gmail.com> <20210805131358.300475-2-hjl.tools@gmail.com> Date: Thu, 12 Aug 2021 10:36:30 +0200 In-Reply-To: <20210805131358.300475-2-hjl.tools@gmail.com> (H. J. Lu's message of "Thu, 5 Aug 2021 06:13:58 -0700") Message-ID: <87bl63giup.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: libc-alpha@sourceware.org, Szabolcs Nagy , Joseph Myers , "Kirill A . Shutemov" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * H. J. Lu: > diff --git a/manual/ctype.texi b/manual/ctype.texi > index d0618c5c38..28af73ff0e 100644 > --- a/manual/ctype.texi > +++ b/manual/ctype.texi > @@ -1,4 +1,4 @@ > -@node Character Handling, String and Array Utilities, Memory, Top > +@node Character Handling, String and Array Utilities, Tagged Address, To= p > @c %MENU% Character testing and conversion functions > @chapter Character Handling Allegedly, it should not be necessary to maintain the @node linkage manually (if we remove it). > diff --git a/manual/tagged-address.texi b/manual/tagged-address.texi > new file mode 100644 > index 0000000000..a3929a0eb7 > --- /dev/null > +++ b/manual/tagged-address.texi > @@ -0,0 +1,80 @@ > +@node Tagged Address, Character Handling, Memory, Top > +@c %MENU% Tagged address functions and macros > +@chapter Tagged Address > + > +By default, the number of the address bits used in address translation > +is the number of address bits. But it can be changed by ARM Top-byte > +Ignore (TBI) or Intel Linear Address Masking (LAM). Current spelling is =E2=80=9CArm=E2=80=9D, I think. > +@Theglibc{} provides several functions and macros in the header file > +@file{sys/tagged-address.h} to manipulate tagged address bits, which is > +the number of the address bits used in address translation, with > +restrictions: Aren't the tagged address bits *not* used in address translation? The Arm documentation implies that the tag bits are those that are ignored for address translation purposes (e.g., =E2=80=9CThe syscall behaviour for a valid tagg= ed pointer is the same as for the corresponding untagged pointer.=E2=80=9D). = This manual change uses the reverse terminology: tagged address bits are those that are used in address translation (including the untranslated intra-page offset). I find it more intuitive to refer to the ignored bits as =E2=80=9Ctagged ad= dress bits=E2=80=9D. > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask}) > +@standards{GNU, sys/tagged-address.h} > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} > +Set the mask for address bits used in address translation to @var{mask}. > +Only bits set in @var{mask} will be used in address translation. The > +return value is @code{0} on success and @code{-1} on failure. This > +function can be called only once before @code{main}. Again the restriction around @code{main} is unclear. If it's =E2=80=9Cbefo= re allocating memory=E2=80=9D or =E2=80=9Cbefore starting threads=E2=80=9D, th= an we should say that. I still don't see a way how we can split tag address bits used by the implementation (glibc, sanitizers) and the application. For example, glibc could use a tag bit to indicate whether an allocation is in a mmap-based allocation. This way, we could use an out-of-line object header (found via a hash table, for example), and utilize the fact that mmap-based allocations are always page-aligned. This would no core malloc algorithm changes and should be an obvious improvement. With more substantial changes, we could use another bit to encode that an allocation is in a small objects region and does not have an immediately preceding object header, either. Introducing small object regions is a much larger change, though. Thanks, Florian