[RFA] A few ui_out formatting bugs with commands-on-breakpoints

[RFA] A few ui_out formatting bugs with commands-on-breakpoints

[Jason Molenda]

Hi, it looks like there were a few small oversights in the ui
support of printing-commands-on-breakpoints.  With the current gdb,
you enter these commands:

   (gdb) b main
   (gdb) comm
   > if $testval == 0
    >   print "true"
    > else
    >   print "false"
    > end
   > print "done"
   > end
   (gdb)

And this is how it's printed:

   (gdb) info br
   Num Type           Disp Enb Address    What
   1   breakpoint     keep y   0x08071a9e in main at ../../src3/gdb/main.c:714
           if if $testval == 0
             print "true"
           elseelse
             print "false"
   end        end
           print "done"
   (gdb)

Not quite ideal. :-)  With the attached patch, the output is

   (gdb) info br
   Num Type           Disp Enb Address    What
   1   breakpoint     keep y   0x08070f30 in captured_command_loop
                                          at ../../src2/gdb/main.c:1
           if $testval == 0
             print "true"
           else
             print "false"
           end
           print "done"
   (gdb)

The 'while' command has a similar problem.  There aren't any
testsuite regressions with this change.

My only concern is that I'm unfamiliar with the UI_OUT suite of
functions.  Are certain ui_out functions are preferred over others?
For instance, we have "end" printed out by both ui_out_field_string()
and by ui_out_text().  I removed the first occurrence in each case,
but who knows, maybe there's a reason to do it the other way.  From
what I can tell in the uiout doco, it's six of one and half a dozen
of the other.

Jason
From kettenis@wins.uva.nl Sat Sep 08 03:19:00 2001
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb-patches@sources.redhat.com
Subject: [PATCH] Add forward declaration of `struct block' to gdbtypes.h
Date: Sat, 08 Sep 2001 03:19:00 -0000
Message-id: <200109081019.f88AJOO00300@delius.kettenis.local>
X-SW-Source: 2001-09/msg00103.html
Content-length: 865

See the #include file policy "discussion" on the discussion list.
This makes `gdbtypes.h' (more) self-contained without sucking in
`symtab.h'.

Checked in.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* gdbtypes.h (struct block): Add forward declaration.

Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.15
diff -u -p -r1.15 gdbtypes.h
--- gdbtypes.h 2001/09/05 23:07:32 1.15
+++ gdbtypes.h 2001/09/08 10:16:03
@@ -23,6 +23,9 @@
 #if !defined (GDBTYPES_H)
 #define GDBTYPES_H 1
 
+/* Forward declarations for prototypes.  */
+struct block;
+
 /* Codes for `fundamental types'.  This is a monstrosity based on the
    bogus notion that there are certain compiler-independent
    `fundamental types'.  None of these is well-defined (how big is

Re: [RFA] A few ui_out formatting bugs with commands-on-breakpoints

[Fernando Nasser]

Hi Jason,

You are the second person to submit a patch to fix this in a couple of
days.

Unfortunately your patch breaks the MI.  I believe Jackie's patch is
closer
to the right fix.

But thanks for the submission anyway.  Keep updating your sources as I
believe
this will be fixed soon.

Best regards,
Fernando


Jason Molenda wrote:
> 
> Hi, it looks like there were a few small oversights in the ui
> support of printing-commands-on-breakpoints.  With the current gdb,
> you enter these commands:
> 
>    (gdb) b main
>    (gdb) comm
>    > if $testval == 0
>     >   print "true"
>     > else
>     >   print "false"
>     > end
>    > print "done"
>    > end
>    (gdb)
> 
> And this is how it's printed:
> 
>    (gdb) info br
>    Num Type           Disp Enb Address    What
>    1   breakpoint     keep y   0x08071a9e in main at ../../src3/gdb/main.c:714
>            if if $testval == 0
>              print "true"
>            elseelse
>              print "false"
>    end        end
>            print "done"
>    (gdb)
> 
> Not quite ideal. :-)  With the attached patch, the output is
> 
>    (gdb) info br
>    Num Type           Disp Enb Address    What
>    1   breakpoint     keep y   0x08070f30 in captured_command_loop
>                                           at ../../src2/gdb/main.c:1
>            if $testval == 0
>              print "true"
>            else
>              print "false"
>            end
>            print "done"
>    (gdb)
> 
> The 'while' command has a similar problem.  There aren't any
> testsuite regressions with this change.
> 
> My only concern is that I'm unfamiliar with the UI_OUT suite of
> functions.  Are certain ui_out functions are preferred over others?
> For instance, we have "end" printed out by both ui_out_field_string()
> and by ui_out_text().  I removed the first occurrence in each case,
> but who knows, maybe there's a reason to do it the other way.  From
> what I can tell in the uiout doco, it's six of one and half a dozen
> of the other.
> 
> Jason
> 
>   ------------------------------------------------------------------------
> 
>    paName: pa
>      Type: Plain Text (text/plain)

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA] A few ui_out formatting bugs with commands-on-breakpoints

[Jackie Smith Cashion]

Jason Molenda wrote:
> 
> My only concern is that I'm unfamiliar with the UI_OUT suite of
> functions.  Are certain ui_out functions are preferred over others?
> For instance, we have "end" printed out by both ui_out_field_string()
> and by ui_out_text().  I removed the first occurrence in each case,
> but who knows, maybe there's a reason to do it the other way.  From
> what I can tell in the uiout doco, it's six of one and half a dozen
> of the other.

I was uncertain about which flavor of ui_out to use also. From
Fernando's explanation and an off list comment I received from someone
else I learned that the really important information should be output
via ui_out_field_*. ui_out_text and it's derivative ui_out_spaces are
just for making the output "pretty" in the generic command line form of
GDB. GUI front ends to GDB typically write the output from
ui_out_field_* to a window but may completely ignore the output from
ui_out_text and ui_out_spaces.

This was not obvious to me when reviewing the implementation of the
UI_OUT functions.

-- 

Jackie Smith Cashion

Re: [RFA] A few ui_out formatting bugs with commands-on-breakpoints

[Eli Zaretskii]

> Date: Sun, 09 Sep 2001 09:45:59 -0500
> From: Jackie Smith Cashion <jsmith@redhat.com>
> 
> I was uncertain about which flavor of ui_out to use also. From
> Fernando's explanation and an off list comment I received from someone
> else I learned that the really important information should be output
> via ui_out_field_*. ui_out_text and it's derivative ui_out_spaces are
> just for making the output "pretty" in the generic command line form of
> GDB.

Perhaps you, or the person who wrote to you, could post those comments
here.  Then we could amend gdbint.texinfo to include that information.

> This was not obvious to me when reviewing the implementation of the
> UI_OUT functions.

Did you read the documentation of UI_OUT functions in gdbint.texinfo,
and if you did, did you find that information missing from there as
well?  If something is missing, could you please suggest what to add
to the docs to make it more useful?