Re: Option to elide single-bit bitfields when printing structures

Re: Option to elide single-bit bitfields when printing structures

[Daniel Berlin]

Eli Zaretskii <eliz@delorie.com> writes:

> > From: "Zack Weinberg" <zackw@stanford.edu>
> > Date: Thu, 22 Feb 2001 11:56:33 -0800
> > 
> > (gdb) p decl->common
> > $1 = {chain = 0x40253000, type = 0x40253138, code = FUNCTION_DECL, 
> >   side_effects_flag = 0, constant_flag = 0, addressable_flag = 0, 
> >   volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0, 
> >   asm_written_flag = 0, used_flag = 0, nothrow_flag = 0, static_flag = 0, 
> >   public_flag = 1, private_flag = 0, protected_flag = 0, bounded_flag = 0, 
> >   lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, 
> >   lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, dummy = 0}
> > 
> > It's hard to see which are set and which aren't.  With this patch, you
> > can get it printed like this:
> > 
> > (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.

>  What if there
> are more than one set flag in your example?
There is.
>  What if the bit fields
> span more than one bit?

It prints them the normal way.

>  I don't see how your suggestion would deal
> with these cases in a way that the resulting display is
> self-explaining.  That trailing "public_flag" is already hard to
> understand; I stared at it for a few moments without understanding
> what's going on here, before it hit me.
> 
> Perhaps we need a special command or a special format that would put
> the burden on the user.  For example, if the user specifies exactly
> what flags (set or unset) does she want to see, the display doesn't
> need to explain that, because the user asked for it.

Errr, it only elides the display if you set a command specifically.
It defaults to the old behavior.

Re: Option to elide single-bit bitfields when printing structures

[Michael Snyder]

Eli Zaretskii wrote:
> 
> > From: "Zack Weinberg" <zackw@stanford.edu>
> > Date: Thu, 22 Feb 2001 11:56:33 -0800
> >
> > (gdb) p decl->common
> > $1 = {chain = 0x40253000, type = 0x40253138, code = FUNCTION_DECL,
> >   side_effects_flag = 0, constant_flag = 0, addressable_flag = 0,
> >   volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0,
> >   asm_written_flag = 0, used_flag = 0, nothrow_flag = 0, static_flag = 0,
> >   public_flag = 1, private_flag = 0, protected_flag = 0, bounded_flag = 0,
> >   lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0,
> >   lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, dummy = 0}
> >
> > It's hard to see which are set and which aren't.  With this patch, you
> > can get it printed like this:
> >
> > (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_?  What if there
> are more than one set flag in your example?  What if the bit fields
> span more than one bit?  I don't see how your suggestion would deal
> with these cases in a way that the resulting display is
> self-explaining.  That trailing "public_flag" is already hard to
> understand; I stared at it for a few moments without understanding
> what's going on here, before it hit me.
> 
> Perhaps we need a special command or a special format that would put
> the burden on the user.  For example, if the user specifies exactly
> what flags (set or unset) does she want to see, the display doesn't
> need to explain that, because the user asked for it.
> 
> >       * cp-valprint.c (elide_bitflag_print): New flag.
> >       (cp_print_value_fields): If elide_bitflag_print, skip printing
> >       single-bit fields whose value is zero entirely, and skip
> >       printing the value for single-bit fields whose value is one.
> >       (_initialize_cp_valprint): Add 'set print elide-bitflags'
> >       command, default to old behavior.
> 
> If these changes are approved by the cp-valprint maintainer, please
> add some minimal changes in gdb.texinfo which describe this feature.

I don't think this feature is necessary.  This is just an
instance of special display of data.  This is what the 
gdb scripting language is for.

Re: Option to elide single-bit bitfields when printing structures

[Zack Weinberg]

On Fri, Feb 23, 2001 at 10:05:16AM -0800, Michael Snyder wrote:
> 
> I don't think this feature is necessary.  This is just an
> instance of special display of data.  This is what the 
> gdb scripting language is for.

Is it, then, possible to write a gdb macro which can display an
arbitrary structure type in this fashion?  As far as I know, I would
have to write individual macros for each structure I wanted to see
specially.  The feature I added works with every structure.

zw

Re: Option to elide single-bit bitfields when printing structures

[Zack Weinberg]

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

Re: Option to elide single-bit bitfields when printing structures

[Eli Zaretskii]

On Sat, 24 Feb 2001, Zack Weinberg wrote:

> > 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.

I thought you were proposing a general-purpose feature, not something 
specific to GCC.  If this is GCC-specific, I tend to agree with Michael: 
throw together a bunch of special-purpose commands using the GDB 
scripting facilities, put them on .gdbinit distributed with GCC, and be 
done with it.  That's what Emacs does, for example.

> 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.

Perhaps it would be better to make the GCC prettyprinter more robust in 
the face of such calamities.  After all, GDB doesn't do anything that any 
other program cannot do, to avoid crashing when accessing invalid 
addresses and corrupted data structures.

Re: Option to elide single-bit bitfields when printing structures

[Eli Zaretskii]

On Sat, 24 Feb 2001, Zack Weinberg wrote:

> On Fri, Feb 23, 2001 at 10:05:16AM -0800, Michael Snyder wrote:
> > 
> > I don't think this feature is necessary.  This is just an
> > instance of special display of data.  This is what the 
> > gdb scripting language is for.
> 
> Is it, then, possible to write a gdb macro which can display an
> arbitrary structure type in this fashion?  As far as I know, I would
> have to write individual macros for each structure I wanted to see
> specially.

How many such structures are there in the GCC sources?

Re: Option to elide single-bit bitfields when printing structures

[Zack Weinberg]

On Sun, Feb 25, 2001 at 09:52:11AM +0200, Eli Zaretskii wrote:
> 
> On Sat, 24 Feb 2001, Zack Weinberg wrote:
> 
> > On Fri, Feb 23, 2001 at 10:05:16AM -0800, Michael Snyder wrote:
> > > 
> > > I don't think this feature is necessary.  This is just an
> > > instance of special display of data.  This is what the 
> > > gdb scripting language is for.
> > 
> > Is it, then, possible to write a gdb macro which can display an
> > arbitrary structure type in this fashion?  As far as I know, I would
> > have to write individual macros for each structure I wanted to see
> > specially.
> 
> How many such structures are there in the GCC sources?

At least 20.

zw

Re: Option to elide single-bit bitfields when printing structures

[Zack Weinberg]

On Sun, Feb 25, 2001 at 09:51:13AM +0200, Eli Zaretskii wrote:
> 
> On Sat, 24 Feb 2001, Zack Weinberg wrote:
> 
> > > 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.
> 
> I thought you were proposing a general-purpose feature, not something 
> specific to GCC.

I am proposing a general-purpose feature.  The GCC usage is a specific
example of why it would be useful.

> > 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.
> 
> Perhaps it would be better to make the GCC prettyprinter more robust in 
> the face of such calamities.  After all, GDB doesn't do anything that any 
> other program cannot do, to avoid crashing when accessing invalid 
> addresses and corrupted data structures.

Oh really?  GDB gets a nice EFAULT/EIO error return from ptrace(2)
when it tries to dereference wild pointers.  The prettyprinter runs in
inferior context and gets SIGSEGV when it does that.  We'd have to
trap it and longjmp out.  The complexity cost would be huge.

Unless you're saying GCC could ptrace itself...

zw

Re: Option to elide single-bit bitfields when printing structures

[Eli Zaretskii]

> Date: Tue, 27 Feb 2001 00:16:52 -0800
> From: "Zack Weinberg" <zackw@Stanford.EDU>
> > 
> > > > 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.
> > 
> > I thought you were proposing a general-purpose feature, not something 
> > specific to GCC.
> 
> I am proposing a general-purpose feature.  The GCC usage is a specific
> example of why it would be useful.

The question is whether there are other examples of why such a limited
functionality, whereby only single-bit fields which are set can be
easily displated, would be useful.  My experience with debugging
several large applications (which doesn't include debugging GCC) seems
to say NO.  But that's just me.

> > Perhaps it would be better to make the GCC prettyprinter more robust in 
> > the face of such calamities.  After all, GDB doesn't do anything that any 
> > other program cannot do, to avoid crashing when accessing invalid 
> > addresses and corrupted data structures.
> 
> Oh really?  GDB gets a nice EFAULT/EIO error return from ptrace(2)
> when it tries to dereference wild pointers.  The prettyprinter runs in
> inferior context and gets SIGSEGV when it does that.  We'd have to
> trap it and longjmp out.  The complexity cost would be huge.

What's so complex about a longjmp?  Perhaps I'm missing something,
since I never debugged GCC seriously.

Also, on some OSes, there are system calls and library functions to
check whether a given address is valid or not.

Re: Option to elide single-bit bitfields when printing structures

[Daniel Berlin]

Eli Zaretskii <eliz@delorie.com> writes:

> > Date: Tue, 27 Feb 2001 00:16:52 -0800
> > From: "Zack Weinberg" <zackw@Stanford.EDU>
> > > 
> > > > > 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.
> > > 
> > > I thought you were proposing a general-purpose feature, not something 
> > > specific to GCC.
> > 
> > I am proposing a general-purpose feature.  The GCC usage is a specific
> > example of why it would be useful.
> 
> The question is whether there are other examples of why such a limited
> functionality, whereby only single-bit fields which are set can be
> easily displated, would be useful.  My experience with debugging
> several large applications (which doesn't include debugging GCC) seems
> to say NO.  But that's just me.

I see this type of thing all over the applications i look at, which
consists mainly of compilers and operating systems.

--Dan

Re: Option to elide single-bit bitfields when printing structures

[Michael Snyder]

Eli Zaretskii wrote:
> 
> > Date: Tue, 27 Feb 2001 00:16:52 -0800
> > From: "Zack Weinberg" <zackw@Stanford.EDU>
> > >
> > > > > 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.
> > >
> > > I thought you were proposing a general-purpose feature, not something
> > > specific to GCC.
> >
> > I am proposing a general-purpose feature.  The GCC usage is a specific
> > example of why it would be useful.
> 
> The question is whether there are other examples of why such a limited
> functionality, whereby only single-bit fields which are set can be
> easily displated, would be useful.  My experience with debugging
> several large applications (which doesn't include debugging GCC) seems
> to say NO.  But that's just me.

No, its you plus me (at least).  GDB is not really set up to facilitate
a diverse set of features for individual commands.  I am in favor of a
relatively high standard of usefulness before adding a feature.  Too many
features would definitely tend to spoil the soup.