From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by sourceware.org (Postfix) with ESMTPS id A7A8F3857836 for ; Fri, 28 May 2021 19:18:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A7A8F3857836 Received: by mail-qk1-x734.google.com with SMTP id j189so5179673qkf.2 for ; Fri, 28 May 2021 12:18:22 -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=g6j0XyMtoOac3TxQRE8hDakcr3zZYdRLKmJitGx6zBw=; b=AdBBYfaaprlNwTrJj3t7GDv72i0N1sljdjrQto9FWvPziW2gs1xTNC+F4HLJnYFaHl maAvzCAowO32u4ptNeCcP6YPW63+P0WIjgnCjhYF1PDSUPKiODoxHd6na1TqGufnVima GNt2LKfn3CJIkfIHnoScpEGGlYCbpXjieymOMGic0tM8oyF0PMBNaVFiigSijckAhRxQ rzqeaJRDwIcM1sehvyNiYwtV5j3b8jhuDnhHtihcK5lrBGusiQlaKwm1HyZi0boQUhfk A+6WKlhcijWq44RSNKIziJS2nnXnkovUEzmz8AMHkFBLgXvhfFkB/F/KQ/49MWPdtICB TIdg== X-Gm-Message-State: AOAM533UO30ygOatpWUfHf60fcfwCn/jrDH1UXNs6T+evPvu5oul2SK8 r0yKEvuIqocPBK3rXZJkkmkAEO49AYMqYQ== X-Google-Smtp-Source: ABdhPJwfE0iizRnWvUE8REUkcFL+H811HAI4QR/Xfm2m/ceUk/m/mbH0EgbK8mXluL4VeiCW9oszfQ== X-Received: by 2002:a05:620a:951:: with SMTP id w17mr5143525qkw.50.1622229502179; Fri, 28 May 2021 12:18:22 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:5c9d:24c3:8899:90c4:5b2? ([2804:7f0:4841:5c9d:24c3:8899:90c4:5b2]) by smtp.gmail.com with ESMTPSA id b18sm3875779qtt.7.2021.05.28.12.18.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 May 2021 12:18:21 -0700 (PDT) Subject: Re: [PATCH] Fix printing of non pointer types when memory tagging is enabled To: John Baldwin , gdb-patches@sourceware.org References: <20210518202004.3492036-1-luis.machado@linaro.org> <579a4169-9f1c-0bc6-9f61-f9e777fa85a0@FreeBSD.org> From: Luis Machado Message-ID: <6f18950b-04be-45ef-4a40-a52512485044@linaro.org> Date: Fri, 28 May 2021 16:18:18 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <579a4169-9f1c-0bc6-9f61-f9e777fa85a0@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, BODY_8BITS, 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: Fri, 28 May 2021 19:18:24 -0000 On 5/28/21 4:08 PM, John Baldwin wrote: > On 5/18/21 1:20 PM, Luis Machado via Gdb-patches wrote: >> When the architecture supports memory tagging, we handle pointer types >> in a special way, so we can validate tags and show mismatches. >> @@ -1266,18 +1266,22 @@ print_value (value *val, const >> value_print_options &opts) >>   static bool >>   should_validate_memtags (struct value *value) >>   { >> -  if (target_supports_memory_tagging () >> -      && gdbarch_tagged_address_p (target_gdbarch (), value)) >> -    { >> -      gdb_assert (value != nullptr && value_type (value) != nullptr); >> +  gdb_assert (value != nullptr && value_type (value) != nullptr); >> -      enum type_code code = value_type (value)->code (); >> +  enum type_code code = value_type (value)->code (); >> -      return (code == TYPE_CODE_PTR >> -          || code == TYPE_CODE_REF >> -          || code == TYPE_CODE_METHODPTR >> -          || code == TYPE_CODE_MEMBERPTR); >> +  try >> +    { >> +      if (code == TYPE_CODE_PTR >> +      && target_supports_memory_tagging () >> +      && gdbarch_tagged_address_p (target_gdbarch (), value)) >> +    return true; > > Hmm, so why only TYPE_CODE_PTR in the new code but TYPE_CODE_REF and > method/member pointers in the old? > My assessment of the situation wasn't entirely correct (too optimistic). Trying to handle all of these types in such a high level function is very complex and very error-prone. This is, in part, due to how GDB bends the handling of some types in order to show the data the user wants. Even the type-handling functions run into some conversion issues sometimes. The member pointers, more specifically, are not even regular pointers, but a TYPE_CODE_INT of 16 bytes. Trying to interpret that as a pointer so we can do memory tag operations runs into conversion limitations of GDB's type-casting system. Handling only TYPE_CODE_PTR is guaranteed to have the desired effect, since we want to be able to show the pointer's logical tag and also potentially want to set the allocation tag for the memory tag granule that pointer points to. A value of type TYPE_CODE_PTR will always have a valid value_address () return. We can handle all the other types in the default way. There is obviously room for improvement in terms of what types we should/should not handle, but right now handling TYPE_CODE_PTR gives very useful results for the most common use cases.