Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Zack Weinberg" <zackw@Stanford.EDU>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: dberlin@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: Option to elide single-bit bitfields when printing structures
Date: Sat, 24 Feb 2001 13:10:00 -0000	[thread overview]
Message-ID: <20010224131046.E13956@wolery.stanford.edu> (raw)
In-Reply-To: <6137-Fri23Feb2001183455+0200-eliz@is.elta.co.il>

On Fri, Feb 23, 2001 at 06:34:55PM +0200, Eli Zaretskii wrote:
> > > > (gdb) set print elide-bitflags on
> > > > (gdb) p decl->common
> > > > $2 = {chain = 0x40253000, type = 0x40253138, code = 
> > > >       FUNCTION_DECL, public_flag}
> > > > 
> > > > which is, IMHO, much easier to read.
> > > 
> > > What if someone wants to know which flags are _reset_?
> > 
> > Nobody really does, it wouldn't make sense.
> > You know what isn't set because it's not shown.
> 
> Then IMHO this feature is less helpful than it could be.  See the list
> above: can you really remember all of the flags if they are not shown?
> And if half of them are shown, is it really easy to know which are and
> which aren't?

Perhaps you are not familiar with the way these flags get used in gcc.
It is very rare that more than two or three are set on any particular
structure, and the ones which are not set are generally irrelevant.
Further, there are so many of them that it can be next to impossible
to see which are set and which aren't in GDB's usual display.

GCC already has a prettyprinter you can call from the debugger for
these things, which obeys the same convention.  The problem with it is
that if the structure is damaged, the prettyprinter is liable to
crash.  So it would be nice if GDB's inspection facility were capable
of the same sort of printout.

> If I need to know about only one flag, I'd rather do this:
> 
>   (gdb) p decl->common.public_flag != 0

Thing is, I don't want to know about only one flag.  I want to know
about whichever flags happen to be set on this structure I've got
here.  I don't know which they are in advance.

zw


  parent reply	other threads:[~2001-02-24 13:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20010222115633.B11707@wolery.stanford.edu>
     [not found] ` <200102230756.CAA06304@indy.delorie.com>
2001-02-23  7:03   ` Daniel Berlin
     [not found]     ` <6137-Fri23Feb2001183455+0200-eliz@is.elta.co.il>
2001-02-24 13:10       ` Zack Weinberg [this message]
2001-02-24 23:53         ` Eli Zaretskii
2001-02-27  0:17           ` Zack Weinberg
2001-02-27 11:04             ` Eli Zaretskii
2001-02-27 11:44               ` Daniel Berlin
2001-02-27 14:41               ` Michael Snyder
2001-02-23 10:09   ` Michael Snyder
2001-02-24 13:05     ` Zack Weinberg
2001-02-24 23:54       ` Eli Zaretskii
2001-02-27  0:13         ` Zack Weinberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010224131046.E13956@wolery.stanford.edu \
    --to=zackw@stanford.edu \
    --cc=dberlin@redhat.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox