From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17049 invoked by alias); 4 Feb 2016 00:08:14 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 17034 invoked by uid 89); 4 Feb 2016 00:08:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=that'll, thatll, Hx-languages-length:1298 X-HELO: mail-oi0-f73.google.com Received: from mail-oi0-f73.google.com (HELO mail-oi0-f73.google.com) (209.85.218.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 04 Feb 2016 00:08:13 +0000 Received: by mail-oi0-f73.google.com with SMTP id i14so820703oig.0 for ; Wed, 03 Feb 2016 16:08:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:message-id:date:subject:from:to :content-type; bh=MoKAZ62Y67ajmUL+LrWqTWBk0Z/zQJZMHnZgy+RIMMg=; b=W88k+rRZ6Ip7vgCjmRpRSh9QxWxrixj2Z5X71xkAY3orfm1tnRaJlnDQ8RKGafw6qr UyXaJ/OoXsyTvJnBjdkYAvrxvdPrli0lY69M2OcsuVsFBX9kMlQH7w2RNWlHmX4Divof JZkgnyKAzoHUzw/Hbuz+pvjZxr/i1HKA92f5YZvAv15M1qkRGwb3ykZY7fCBrNTI943e qh0cYQX8twcKcTCwtVO8ZW9Vev/TBLVpfbspW8anT8G6DlKsuGo2pypUbV83VL6uGiVM 4ye31O7KGd1nXXkZbGXr9zBGr/e66c7qbBQXvt1mz+1kmd2Tr2030Th1/iguuTHx8G3k aMsQ== X-Gm-Message-State: AG10YOTXtaGXirBqLI3Fkr7bNVFNWljIDbYfhPif2+R0abqgY5GIlEMMRqScRjtyGnPxLvsCTPG1GKIjiIiJfCAM+G3NPUSe6Hhra7EOJOXvSeRMkrzaDA9Zq96NPJY6cwn+z7HqQuQSx36JnREO6ADgnPGt6+3sX3RkAHl4UCOIq94D57hT0A== MIME-Version: 1.0 X-Received: by 10.51.17.34 with SMTP id gb2mr1168226igd.10.1454544491151; Wed, 03 Feb 2016 16:08:11 -0800 (PST) Message-ID: <001a1135ed32b4c71c052ae6879a@google.com> Date: Thu, 04 Feb 2016 00:08:00 -0000 Subject: Flags fields in register xml descriptions are suboptimal: What to do? From: Doug Evans To: gdb-patches@sourceware.org Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes X-IsSubscribed: yes X-SW-Source: 2016-02/txt/msg00101.txt.bz2 Hi. I'm thinking about making "cpsr" in the aarch64 port pretty-print better, like how we print eflags for x86. However, there is a problem (I think - maybe there's an alternative I'm missing). Some fields are more than one bit (e.g., EL), so what to do? AFAICT "flags" fields in register xml descriptions have a pretty hardwired assumption that every field is one bit. There is code that loops over the fields assuming each field's number is also its bit position. Bleah! I could use a struct, but it won't, I think(!), give me a mechanism to print the kind of output I want. E.g., (gdb) i r cpsr cpsr 0xa0000020 123456 [ Z N EL=1 ] [Obviously I just made integer values up.] Question: What do people think of allowing the "flags" type in register xml descriptions to support fields larger than one bit? Such fields would print as NAME=value (or some such). --- Also, I'd like to print flags even if they're zero. E.g., (gdb) i r cpsr cpsr 0xa0000020 123456 [ Z !C N !V EL=1 ... ] or some such. IOW, instead of not printing fields that are zero/false/off, print them as "!FIELD". That'll change x86 eflags printing and maybe some won't like that. I could make it some kind of option, but it feels like featuritis.