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.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,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 AFF8B1F8C6 for ; Fri, 20 Aug 2021 23:27:28 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id ECB16385383C for ; Fri, 20 Aug 2021 23:27:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ECB16385383C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629502047; bh=AXiWXNxBs46MjChESbCpeLZq1bJz5ps/uNYivy4s+fs=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=H213mrTuijNgOVdXHiXK1tbanqoIH180yTD8ui33s374UZTUSiXzCuA2EDML8eNn2 qrn9147xOogtLjBRiGgrhN9m58sfYvEMvK4uvOuRqF1r36TxfcFkzzFmH/9diSpemC P2gEbEO0B1vDUcgOD5EYAxDkMe5+KUjbk7htDq7w= Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id 5C369385842B for ; Fri, 20 Aug 2021 23:27:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C369385842B Received: by mail-pj1-x102e.google.com with SMTP id u13-20020a17090abb0db0290177e1d9b3f7so14947021pjr.1 for ; Fri, 20 Aug 2021 16:27:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AXiWXNxBs46MjChESbCpeLZq1bJz5ps/uNYivy4s+fs=; b=m6sOIoBlzIQKm4BcnSU+Lr/13ld7uU1Dh7JAcMz5SjvOqOhYCVZx7TG9B1rDcQNvjq BqRdl40XgM9HeSVorx6zAVc4iu7n58Hyi2OGRoG1vaWpWc8f+rc5/R2AVutS0HysYLxo vjXjH/mWogFY8Qs5e3VrdflC5vrZ2IzmZ9ehgUEbtwy4kk6jkVhlSZabqo7ZlsDSF6pC RuvOsemiLm7KCYzm/d8ypha5H8S3ZTY9DDG9FwOtEnxn6Ia6D844jcSlDC5F4VnVLXEJ hzg7MnHb4DHiGqB6qHoEPNo35qW4FGkZ8GOV+Krid+lfXkDHDa9tof2RM/ZPbaeF6gfq tfOg== X-Gm-Message-State: AOAM531JkPnNL6086tf2NyfuCoqBHje1Jua+tYs+39f0V5C+dBfObxox smlIs+Q3cvxbmY0jj4de/mjL55WHVJmk9gSr2wM= X-Google-Smtp-Source: ABdhPJzVk9FRey6641gdMv2DCPHXoOftn1boMiEYBDLWfc0/zKfAZp9D9t/pW+VB8ILx0tsE8WBOzcuuiG/ZCEFuOgk= X-Received: by 2002:a17:90a:bc8f:: with SMTP id x15mr6063292pjr.153.1629502025353; Fri, 20 Aug 2021 16:27:05 -0700 (PDT) MIME-Version: 1.0 References: <20210805131358.300475-1-hjl.tools@gmail.com> <20210805131358.300475-2-hjl.tools@gmail.com> <87bl63giup.fsf@oldenburg.str.redhat.com> In-Reply-To: <87bl63giup.fsf@oldenburg.str.redhat.com> Date: Fri, 20 Aug 2021 16:26:29 -0700 Message-ID: Subject: Re: [PATCH v5 1/1] : An API for tagged address To: Florian Weimer 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: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: GNU C Library , Szabolcs Nagy , Joseph Myers , "Kirill A . Shutemov" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Thu, Aug 12, 2021 at 1:36 AM Florian Weimer wrote: > > * 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, = Top > > @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). Since @node isn't removed, I guess I have to keep this change. > > 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. There are contrib.texi:Philip Blundell for the ports to Linux/ARM contrib.texi:(@code{arm-@var{ANYTHING}-linuxaout}) and ARM standalone contrib.texi:Richard Earnshaw for continued support and fixes to the variou= s ARM contrib.texi:his maintainership of the ARM and MIPS architectures and the m= ath contrib.texi:encryption support for ARM and various fixes. creature.texi:architectures (i686, ARM), this is planned to change and applications and contrib.texi:Ulrich Weigand for various fixes to the PowerPC64 and Arm port= s. I will keep ARM. > > +@Theglibc{} provides several functions and macros in the header file > > +@file{sys/tagged-address.h} to manipulate tagged address bits, which i= s > > +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 ta= gged > 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 = address > bits=E2=80=9D. I will rename it to set_translated_address_mask. > > +@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=9Cbe= fore > allocating memory=E2=80=9D or =E2=80=9Cbefore starting threads=E2=80=9D, = than we should say > that. I will change it to This function can be called only once before @code{main} and thread creatio= n. > 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. > Tag usage should be exclusive to glibc. set_translated_address_mask tells glibc that tag will be used for another purpose. Thanks. --=20 H.J.