From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 0E202385802D for ; Fri, 16 Feb 2024 12:01:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E202385802D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0E202385802D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708084864; cv=none; b=x5S+3Gj2tNBV4gXo4zahvRaEJRIauT5cJG5/uassLJIs1K5dWWxaAnUmXmdlnwR0VXUEvIm9OuK5Utdv2r75S0dUmUzQ429pUavP7oXCdmmpvnFQqIl1eK/kjAkvM136xr2ddGAXlIWohRgOF+KF/A2kc526po1xKhv8YOdHaz0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708084864; c=relaxed/simple; bh=zzEWekx8GYKtyNnb4xO6OV22FAHEsH2hVjF3aP5bN0k=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=m/LDUoeFUD4kVW618LaOY6oNZ13UE7f4tOCOS6WhRsN7cnDtUI4i0abbjLtZ7rc7HnFwv9NdMipdusMIfh9Fj2ZVeb8k5JrwLVJiX4nyQZOp64TNu1yMTyfUnt01S/25KljvH9lrlom+pXCbJ/ywwsfP0IT1744Oa/8FocKqP0E= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1708084862; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9m7OZBXBgmbzsP/VlU0jlP26IpMRCdfmncHrjEuugI4=; b=Czs0ycg6LVWA6h05jtMiiWOApe9xdOAZ017AkYMzxcv8OoDcjX/9C/8KspzQ87Wk0UsiWG Cj7MHe2bZ4Eswrt8D9xEV8pqRw2ZJeV+Xj6pNCKHGGpaR0q60etHyja3e4n01c3GFK7zIr avCMfyfEFpg9vIezkQA3o66I6MUKRIg= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-265-JAYwcvASN-KXFG0GZg--XA-1; Fri, 16 Feb 2024 07:01:01 -0500 X-MC-Unique: JAYwcvASN-KXFG0GZg--XA-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-33d256ca4c8so18531f8f.3 for ; Fri, 16 Feb 2024 04:01:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708084860; x=1708689660; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=9m7OZBXBgmbzsP/VlU0jlP26IpMRCdfmncHrjEuugI4=; b=j0BK8Oh+rSNG2IxosVqj2d0xdIuAnvikcK+6cT/ah+7kSXURl7j/5mOUkypK9Y6xXj nf12mCwzWBGtzVvEKNWwwaWe22b7ubW6fuyoPDP6gjUFxjbLCyCgiGSFp/VjEji0ORdQ mBZ/42FcfpVU5mgAifFG6taSWbdCbHZi7H5sYTspFvU4r7gonFHsK6HxeswmPPK+k9CU QY/sPoDxjDZctKEF5BVPxe9iJdadWuCYJv0ceTa/fdBWqsKXLsnB3GVMIm8qp29TZFE4 Z9rohEkCmBP5k4/P4JlYRiRDOZ0xh3d3psWHaclfW0Z3zRkFKV6JUp6YmR5cK1OG4UfT 7gxQ== X-Forwarded-Encrypted: i=1; AJvYcCUjvCm+gtI6g2UWahyEiaIiJu8Juojih9PHvQwaqQa6yh58ZKUWT6YHHQ/trfljdyZfpZCXHjPCnG6CkZtfB6ejCGw= X-Gm-Message-State: AOJu0Yza9cVuDzl6sc181w30Nj2a6H4myjuU/+FnjkyUz5tRYGNl8juL MW2a1LbT/v08kHX/ZJH1RPiC1RiHZG6q+0HrQqA7lGgyoCdwF6xSoVjqlelMS6jATmHxis1Fvr9 GSeZHqXd2/3i9FISm0VZ00FAUNk3ZUT4GwK/HfBrKSOVaCgWSNRAPasOt X-Received: by 2002:adf:fd0c:0:b0:33b:86c7:bd3a with SMTP id e12-20020adffd0c000000b0033b86c7bd3amr3350404wrr.29.1708084859961; Fri, 16 Feb 2024 04:00:59 -0800 (PST) X-Google-Smtp-Source: AGHT+IFz+SwE93gk5WR6ZpFENtS2JAV2xq5o4v4DmR4eBPI8YY56pLCK44oD2HRoRy1zutIPLQOKbw== X-Received: by 2002:adf:fd0c:0:b0:33b:86c7:bd3a with SMTP id e12-20020adffd0c000000b0033b86c7bd3amr3350384wrr.29.1708084859599; Fri, 16 Feb 2024 04:00:59 -0800 (PST) Received: from [192.168.0.129] (ip-94-112-227-180.bb.vodafone.cz. [94.112.227.180]) by smtp.gmail.com with ESMTPSA id ba20-20020a0560001c1400b0033b4335dce5sm2193437wrb.85.2024.02.16.04.00.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Feb 2024 04:00:59 -0800 (PST) Message-ID: <3d5623f5-082b-4ee3-bdf1-0c2bf5f8b122@redhat.com> Date: Fri, 16 Feb 2024 13:00:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Register View bitfields support To: =?UTF-8?Q?Robert_P=C3=AErvu?= , gdb@sourceware.org Cc: Sebastian Perta , Mark Goodchild References: From: Guinevere Larsen In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 09/02/2024 13:56, Robert Pîrvu via Gdb wrote: > Hello, > > I am a cdt developer and I'm working on a new functionality for > Eclipse's Register View. Hi! I'm replying to this mostly so you're not left out to dry, since I'm not too familiar with the MI interpreter and I never seen anything like this in the CLI interpreter. That said, I do have a few thoughts left inline > > The current implementation of the Register View does not allow the > display of individual fields of a register with bitfields. This > functionality is only available in the Expression view by creating a > new expression using the “$” and the name of the register. > Register view has a grouping functionality that allows us to create > custom groups of registers, those groups can be expanded and collapsed > to show/hide the register in the said group. The same functionality of > expanding and collapsing can be added to a register with bitfield. My first question is: Does GDB already know of these bitfields? I am not sure if it does or not from your description of using Expression View. If we already know, having a convenient way to access them sounds like a good idea. If we don't, are they architecture specific? Is the expectation that we'd keep that information up to date? Or is this something that should (or could) be user-defined? If the latter, the implementation should probably come with a way to define them. Sorry if these questions are very basic, this is pretty far from the bits I work on > > The implementation of this would require the modification of the > -data-list-register-values MI Command to include a list of registers’s > bitfields. > And the introduction of a new MI Command > -data-list-register-bitfields-name, is also needed to retrieve the > names of the bitfields. > > The modified -data-list-register-values would have the following format: > > Command: -data-list-register-values [ --skip-unavailable ] fmt [ ( > regno )*] > Respone: > ^done,register-values=[{number="0",value="0”,bitfields=“{value=0, > value=0}"}, {number="1",value="{0}”,bitfields=“{[]},...] > Format of the response: [{number="0",value="0”,bitfields=“{[value=0], > [value=0]}"}] > > The --skip-unavailable option indicates that only the available > registers are to be returned. > The regno option indicates that only the specified register needs to > be returned. If no register is specified then all registers will be > returned. > The fmt indicates the format according to which the registers' > contents are to be returned. Allowed formats for fmt are: > > Hexadecimal - x > Octal - o > Binary - t > Decimal - d > Raw - r > Natural - N > > If a register doesn't have bitfields, then the bitfields list will be > empty or it can be not included in the response. I think this is a complicated change. I'm not sure how strict we are with output consistency, but I think we have to be pretty consistent to not break every user of the MI protocol, so adding a new field in this return doesn't sound like a great idea to me. I would suggest adding a new option, --with-bitfields for example, which has this output, and leave the default response with the same format. > > The new MI Command will have the following format: > > Command: -data-list-register-bitfield-name [ ( regno )+ ] > Response: ^done,register-bitfield-names=[{name="reg0", bitfields > =["C", "M"]},{name="reg1", bitfields =["A", "B"]}, ...] > > The regno option indicates that only the specified register needs to > be returned. If no register is specified then all registers will be > returned. > > If the register doesn't have bitfields, then the bitfields list will > be empty or not included in the response. When would registers not be included? From the previous paragraph it sounds like they'd always be included, and having empty lists make sense. I don't have any strong opinions on which option is better, just commenting on the current explanation. Either way, this can be worked out when the implementation itself is being discussed in the patches that add it. > > Any feedback regarding this feature is greatly appreciated and we are > open to contribute to its implementation. I think this is a cool idea, regardless if these bitfields are arch-defined or user-defined. If you show up with patches with an implementation for this, I'll be happy to do my best in reviewing them (though I can't approve them for merging), otherwise I think the best way to go about it is opening a feature request (called Request For Enhancement, RFE) on our bug tracker (https://sourceware.org/bugzilla/). You can open the bug yourself or I can open for you if you have troubles with the account creation process. -- Cheers, Guinevere Larsen She/Her/Hers > > Best Regards, > Robert. > >