From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <fmayer@google.com>
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com
 [IPv6:2a00:1450:4864:20::42b])
 by sourceware.org (Postfix) with ESMTPS id BCF6D382C156
 for <gcc@gcc.gnu.org>; Fri,  3 Jun 2022 23:52:52 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BCF6D382C156
Received: by mail-wr1-x42b.google.com with SMTP id u3so12209937wrg.3
 for <gcc@gcc.gnu.org>; Fri, 03 Jun 2022 16:52:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc;
 bh=DZ8/TbQTzokMQy4o7ZTGb8bLiEpEQKLoMidYnu4IN5o=;
 b=AhNsS5h4EjZNCQE9tmdokVIvkFEUeJrkVLmmnYF4KHorIuzU+VnuIEvRDdc/9YrO9H
 V30SUwjVkn9yMol9v+BKK16nZONQVE4X5DVHMHtSLJJfgofihbMh9LFjcUIAGcYVNPvn
 DceVEpg8dYO078shrXrDKYoMM9wUiAZeURHnEbrZ8MPE7bwbiy8Aawdwe0dzjIRMrKQK
 yRlf6ywAbpzoW6B8Uu/aRwXxcKlXnWRLXVETl7w7XYfELPhZBoEgYlEAYCK0pQ01uTry
 Wz4epC5UA3L60g6MQloyMubnu5EMVU2K3Kq84fcTxQRBiBD4SEO4WfDnJNGe4M8a0dwr
 cB4Q==
X-Gm-Message-State: AOAM531gSS0B/Sd0FB3/bCEpgomKpLWkDqkjZkkHcCxS+1L5TckkM3oQ
 4BUiSZPB2OA7+n8jq4K+RnxCm/NqqS0+8Vnia81WzMHYdEmv6A==
X-Google-Smtp-Source: ABdhPJzx0jKPK+nhZ0kguJM6jmTm7K6cyypLnt2nDM0xHvYDhH7PZOS4A/fHIuQ5anVcKjP2qu5UaxbG7NqU7i6ghhY=
X-Received: by 2002:a5d:68d2:0:b0:210:31cc:64a6 with SMTP id
 p18-20020a5d68d2000000b0021031cc64a6mr9972983wrw.679.1654300370363; Fri, 03
 Jun 2022 16:52:50 -0700 (PDT)
MIME-Version: 1.0
From: Florian Mayer <fmayer@google.com>
Date: Fri, 3 Jun 2022 16:52:38 -0700
Message-ID: <CAJAyTCDHRLfxUWARpH5fzis9sqWtuF1PV5MsjLuyYU3LxPx9cA@mail.gmail.com>
Subject: .eh_frame augmentation character for MTE stack tagging
To: gcc@gcc.gnu.org
Cc: Evgenii Stepanov <eugenis@google.com>, Fangrui Song <maskray@google.com>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-17.5 required=5.0 tests=BAYES_00, DKIMWL_WL_MED,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,
 RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE,
 USER_IN_DEF_DKIM_WL,
 USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: gcc@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc mailing list <gcc.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <mailto:gcc-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc>,
 <mailto:gcc-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jun 2022 23:52:54 -0000

Hey!

We are in the process of implementing MTE (Memory Tagging Extension)
stack tagging in LLVM. To support stack tagging in combination with
exceptions, we need to make sure that the unwinder will untag stack
frames, to avoid leaving behind stale tags. As such, we need some way
to communicate to the unwinder to do that.

In a discussion on llvm-dev [1], it was decided the best way to go
forward with this would be to add a new character ('G' for taG, as the
MTE instructions stg etc.) to the eh_frame augmentation string, and
then handle that in libunwind by clearing the tags of the respective
frame.

How does that sound? Would that be a good course of action for GCC as well?

Thanks,
Florian

[1]: https://lists.llvm.org/pipermail/llvm-dev/2020-May/141345.html