From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17117 invoked by alias); 20 Sep 2009 18:35:43 -0000 Received: (qmail 17107 invoked by uid 22791); 20 Sep 2009 18:35:42 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 Sep 2009 18:35:37 +0000 Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id n8KIZZh8023647 for ; Sun, 20 Sep 2009 11:35:35 -0700 Received: from ywh2 (ywh2.prod.google.com [10.192.8.2]) by spaceape8.eur.corp.google.com with ESMTP id n8KIZWhT022013 for ; Sun, 20 Sep 2009 11:35:32 -0700 Received: by ywh2 with SMTP id 2so3034913ywh.27 for ; Sun, 20 Sep 2009 11:35:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.45.8 with SMTP id s8mr6854250ybs.227.1253471731660; Sun, 20 Sep 2009 11:35:31 -0700 (PDT) In-Reply-To: <20090920180036.GA19867@caradoc.them.org> References: <20090918235632.0DDC6843AC@ruffy.mtv.corp.google.com> <20090920180036.GA19867@caradoc.them.org> Date: Sun, 20 Sep 2009 18:35:00 -0000 Message-ID: Subject: Re: [RFC] printing/setting flag register fields From: Doug Evans To: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2009-09/txt/msg00645.txt.bz2 On Sun, Sep 20, 2009 at 11:00 AM, Daniel Jacobowitz wrote: > Just my two cents - flag types were a workaround for GDB's lack of > good pretty-printing facilities. =A0They should be just structs > containing bitfields, with a default pretty-printer. =A0And/or a union > with an accessible integer value. =A0Anywhere that our handling of such > constructs isn't good enough for eflags, it's not good enough for user > code either, and I deal with a lot of code of this nature. I read somewhere that one advantage of TYPE_CODE_FLAGS was that one didn't have to deal with the vagaries of ABI-struct layout. Alas I can't find it now. [And I'm not sure it's really relevant as the data recorded in the underlying type doesn't have to follow ABI rules, so maybe I've confused it with something else.] Should TYPE_CODE_FLAGS be nuked? I'm happy to do that instead if that's what folks want. I like it, but if we made eflags a union of a struct and an int, then "set $eflags.ZF =3D 0" won't work. Are folks happy with "set $eflags.bits.ZF =3D 0"? "works for me". > As for bitfield numbering, I think we should use the corresponding > architecture's conventions; I don't know what the m68k complication > is, though. "works for me". My higher order question, though, is should the bitfield positions be displayed in the output of ptype (for these objects, I wouldn't do it by default in general of course). I like it there so that one doesn't have to look in any manual to know ZF, for example, is in bit 1 << 6 (gdb has so much information internally, we should try to provide more of it to the user). But it could be done differently. An off-the-cuff example is an option to ptype to print field offsets for structs in general. [I'm assuming such a facility doesn't already exist.] That would probably be more useful than always printing the offsets anyway.