From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id A431B3858C39 for ; Thu, 15 Jul 2021 14:37:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A431B3858C39 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 16FEbd06007892 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 10:37:44 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 16FEbd06007892 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 8DD221E54D; Thu, 15 Jul 2021 10:37:39 -0400 (EDT) Subject: Re: Custom types in target description XMLs To: Shahab Vahedi , gdb@sourceware.org References: From: Simon Marchi Message-ID: <429b4e0f-032b-b946-2f59-ff2f729b1005@polymtl.ca> Date: Thu, 15 Jul 2021 10:37:39 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 15 Jul 2021 14:37:39 +0000 X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_ASCII_DIVIDERS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no 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@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 14:37:46 -0000 On 2021-07-13 3:08 p.m., Shahab Vahedi via Gdb wrote: > Hello, > > I have difficulties defining a custom register type in a target > description XML format. For the sake of argument, consider the > 32-bit register below with it's own contrived fields: > > bit: 31 ... 11 10 9 8 7 ... 0 > ,-----------------.---.---.---.---------. > | dont_care_field | g | u | b | version | > `-----------------^---^---^---^---------' > > I've come up with two definitions. One uses the "flag" and the > other uses the "struct" type. However, both have their issues > in representing the correct values. The definitions are as > follows: > > -----------------------------8<----------------------------- > > > > > > > > > > > > > > > > > > > > > > ----------------------------->8----------------------------- > > The value reported by GDBstub (QEMU) is 0x1337 for both registers: > > 0 x 1 3 3 7 > 0001 0011 0011 0111 > > version: 0x37 (55) > b: true > u: true > g: false > > However, this is how GDB prints them: > > ---------------------- [ gdb ] ---------------------- > (gdb) info reg $f_reg > f_reg 0x1337 [ version=0 b u ] > ----------------------------------------------------- > > Here, while "$f_reg" holds the correct value (0x1337), the > "version" field is 0 instead of 55. "b", "u", and "g" fields > are inferred correctly though. > > ---------------------- [ gdb ] ---------------------- > (gdb) info reg $s_reg > s_reg { > version = 0x37, > b = 0xff, > u = 0xff, > g = 0x0 > } { > version = 55, > b = -1, > u = -1, > g = false > } > ----------------------------------------------------- > > The register with struct type on the other hand, interprets > "version" correctly while misjudging the "boolean" fields that > are set. > > Am I doing something wrong or this could be a bug in parsing? > If latter is the case, I will dive into the code to find the > root cause. I just need someone to confirm it first. Hi Shahab, Given the lack of response, I would say that nobody knows that off-hand, and you would need to dive into the code to check what is happening, if it's a GDB bug or something else. Simon