From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) by sourceware.org (Postfix) with ESMTPS id B284E3857C50 for ; Wed, 24 Mar 2021 18:18:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B284E3857C50 Received: by mail-qk1-x72c.google.com with SMTP id 7so18999026qka.7 for ; Wed, 24 Mar 2021 11:18:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pjustq+P8+CDwS7CFv1CxQFYb0o6buaZPybUGeVjS8o=; b=b/zv4/Q/7yz9PlqBcWgI/ajXwY5LLEpA4O8BA2LhbMIjSioWKY1B4On4fE9DHOFtON 36iN5bokdLgbg1tt43Sjybuh9R7U1jXYCmMna5aG3k9rA2Nbk1JPWd35jfec3KYvuUuj r5zUd2V3gpXgenepyD4hcDI/jvPUkQCLPbo4mjU9LcU6+El2AFntMzt+T0flvhBqC4OL Of0LnEE82kg13+bVMC/idvx/MuZ2rKAU8+bySukasKHyxkFt+yaNCdj0seizXHZ1uYp6 KHNXLJvsQsUEXM6G2P47rF8OYszFxv8G4RHWHhVsqypN8VB68hDR7WhIs/M6saTDs60S zCKA== X-Gm-Message-State: AOAM5321ZTzJWvXNphUpZtSkvnCA32/la7HEhPOIgOjFbj4SriL3gUbN bRA+1JJoCC6L0yp15euswLD2nLlOXYENoA== X-Google-Smtp-Source: ABdhPJxyPyG8Qp1gnmEqn5SdFadPHsNl0H2R/4ji3M1CPZeA52B5O8f6Q7H9eLoTeSfMc2qbciZHUw== X-Received: by 2002:a37:a30c:: with SMTP id m12mr4557800qke.300.1616609913172; Wed, 24 Mar 2021 11:18:33 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:2841:ad61:3bf4:83da:f1f1? ([2804:7f0:4841:2841:ad61:3bf4:83da:f1f1]) by smtp.gmail.com with ESMTPSA id g25sm1968157qtq.7.2021.03.24.11.18.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Mar 2021 11:18:32 -0700 (PDT) Subject: Re: [PATCH v6 00/25] Memory Tagging Support + AArch64 Linux implementation To: Simon Marchi , gdb-patches@sourceware.org References: <20210322132120.1202230-1-luis.machado@linaro.org> From: Luis Machado Message-ID: <9c445172-9d20-cc94-5af8-8f8f12a2ce5a@linaro.org> Date: Wed, 24 Mar 2021 15:18:30 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 18:18:35 -0000 Hi Simon, On 3/23/21 7:50 PM, Simon Marchi wrote: > On 2021-03-22 9:20 a.m., Luis Machado via Gdb-patches wrote:> Memory tagging improves memory safety by tagging various parts of memory and >> raising exceptions when the allocation tag (the one associated with a range of >> memory addresses) does not match the logical tag contained in a pointer that is >> used to access the memory area. >> >> We already have an implementation of such a mechanism for sparc64 (ADI), but >> it is target-specific and not exposed to the rest of GDB. This series aims to >> make the infrastructure available to other targets that may wish to support >> their specific memory tagging approaches. For AArch64 Linux this is called >> MTE (Memory Tagging Extensions). >> >> The series is split into a set that deals with generic changes to GDB's >> infrastructure (target methods, gdbarch hooks and remote packets), a set that >> implements support for AArch64 Linux and one last set that implements new >> commands, updates the documentation and adds tests. >> >> The goal is to make it so the architecture independent parts of GDB don't >> need to interpret tag formats, given the formats are likely different >> for each architecture. For this reason, GDB will handle tags as a sequence of >> bytes and will not assume a particular format. >> >> The architecture-specific code can handle the sequence of bytes appropriately. > > Hi Luis, > > Apart from the nits I pointed here and there, this is OK to merge. > Thanks for this big chunk of work! I've addressed those nits and pushed the series now. Thanks a lot for all the reviews and for the patience to go through this series a few times.