From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id F03873854830 for ; Sat, 24 Jul 2021 13:50:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F03873854830 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com Received: by mail-pj1-x1032.google.com with SMTP id j1so6260805pjv.3 for ; Sat, 24 Jul 2021 06:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=qYfOEyUUewrrKWVCRuGN1mgw6ptR7LTUHe1wsagtkBk=; b=OqJEBKl/ebkYWGOVXNTVNuzEda9Wnbbb7qevuX6m9M9M/f0KBDMw2PZWIsW3D/R1hi KpsCDybD/9KeyGAAf8ASMXYBvoTe+BrUJ33Q2QsiuTaRFicCE2Wg+TZHDG8wmxQoLMB1 RI664DtmYb4juAQpkmgzm6oBa3y2F6H/xgQlbplIdy+27G18Dy01imlzwsU8N6Y2OWFR ExJE+QsDj4zQX+5/vimkkVxPr6KFmeACeIExS9yPYbl8sjVxqey5UgNEl8YbyAtXW6HF dS2MkBM+GrmNIxqbUvhD5uBhzn7y6jSETv3qR/KfDPKjygnX/+SZsyux0DkiR7Mmv9Nq qK/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=qYfOEyUUewrrKWVCRuGN1mgw6ptR7LTUHe1wsagtkBk=; b=pk9ZaRTm/qhe56u9cbNh18BuYxbgMD9KHE6zM2iam1AEqy+PjdPchV5giW2SDpocz/ VmofV/YX7KnAQq55A/PPyzfw+QLrtDq70WtboYwexiZSt5HG+5RrP0wIz09ccFpeUlWI bFdkF7OxTAX8vVgg34hrzr956sBNt3xvch8cuoS6yjJbeI7EDqBh/zmymxaIzjYApVnR qcwHkZK3LTGWZ+d5fSHXaZCHI5q+qWG1zCcocjNKaAqF0AhPjEnBxsur57I0y6quKM4v Ujd9NCaZFatv78rvXqX17GhrDM+a81fcM/FePHO3++cUIZOOEk/+EefB89FR/3rRErHd VrXQ== X-Gm-Message-State: AOAM532mQz/lVj41rPvvax1tXE0k2g6323T+BiTmL6BuzQsYdjce/7vI OryeeRHPCiZeIQc+DSdmQl1s X-Google-Smtp-Source: ABdhPJzCski4vOU5PTxkyNS1SRhWlAORwfoyoNaegVih/4jDXrFfqgqoU5x6Q91svflxe0puzK8DgA== X-Received: by 2002:aa7:88d3:0:b029:32b:75d0:fa92 with SMTP id k19-20020aa788d30000b029032b75d0fa92mr9214163pff.23.1627134640065; Sat, 24 Jul 2021 06:50:40 -0700 (PDT) Received: from takamaka.home ([184.69.131.86]) by smtp.gmail.com with ESMTPSA id g71sm13168264pfb.139.2021.07.24.06.50.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Jul 2021 06:50:38 -0700 (PDT) Received: by takamaka.home (Postfix, from userid 1000) id E6F1180097; Sat, 24 Jul 2021 06:50:37 -0700 (PDT) Date: Sat, 24 Jul 2021 06:50:37 -0700 From: Joel Brobecker To: Simon Marchi Cc: Shahab Vahedi , gdb-patches@sourceware.org, Shahab Vahedi , Simon Marchi , Joel Brobecker Subject: Re: [PATCH v2] gdb: Fix numerical field extraction for target description "flags" Message-ID: <20210724135037.GA2278483@adacore.com> References: <20210723123830.16536-1-shahab.vahedi@gmail.com> <7c003060-8c48-9fa7-07eb-4733ef7f30e1@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7c003060-8c48-9fa7-07eb-4733ef7f30e1@polymtl.ca> X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Sat, 24 Jul 2021 13:50:44 -0000 > Shahab expressed (on IRC) the desire to merge this patch in the GDB 11 > branch. That sounds reasonable to me, does it to you? It does to me too. Thanks Simon and Shahab. > On 2021-07-23 9:26 a.m., Simon Marchi via Gdb-patches wrote: > > On 2021-07-23 8:38 a.m., Shahab Vahedi via Gdb-patches wrote: > >> From: Shahab Vahedi > >> > >> v2 (This section will be removed when checking the patch in): > >> 1. There are no lines in the commit message starting with "---". > >> 2. Joined 2 lines together that now fit under character limits. > >> 3. Added the unit-test "test_print_flags" as proposed by Simon. > >> > >> The "val_print_type_code_flags ()" function is responsible for > >> extraction of fields for "flags" data type. These data types are > >> used when describing a custom register type in a target description > >> XML. The logic used for the extraction though is not sound: > >> > >> unsigned field_len = TYPE_FIELD_BITSIZE (type, field); > >> ULONGEST field_val > >> = val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1); > >> > >> TYPE_FIELD_BITSIZE: The bit length of the field to be extracted. > >> TYPE_FIELD_BITPOS: The starting position of the field; 0 is LSB. > >> val: The register value. > >> > >> Imagine you have a field that starts at position 1 and its length > >> is 4 bits. According to the third line of the code snippet the > >> shifting right would become "val >> -2", or "val >> 0xfff...fe" > >> to be precise. That will result in a "field_val" of 0. > >> > >> The correct extraction should be: > >> > >> ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field); > >> > >> The rest of the algorithm that masks out the higher bits is OK. > >> > >> Co-Authored-By: Simon Marchi > > > > LGTM, thanks. > > > > Simon > > -- Joel