[RFC/RFA] avoid spurious Watchpoint X output on cygwin native target.

[RFC/RFA] avoid spurious Watchpoint X output on cygwin native target.

[Pierre Muller]

The following patch suppresses all 
spurious output when a DLL is loaded in native cygwin GDB.

Its a RFC for two reasons:

First reason:
Question:  Why do we currently get ouptut while loading a DLL
while the safe_symbol_file_add does redefine gdb_stdout and 
gdbstderr to dummy output exactly to suppress all output?

Answer: Because, despite gdb_stdout is redefined as a 
dummy file does noting with the strings it gets
(and thus is a correct way of suppressing ouptut 
sent to gdb_stdout), the Watchpoint X...
message is sent to uiout struct
(see mention function in breakpoint.c source)
The only question here is if a change of gdb_stdout should not 
also change the global uiout variable behavior.
This could easily be achieved by replacing 
the stream field of the data field of ui_out struct into a 
'** ui_file' instead of a simple '*ui_file'.

   Is that complete nonsense, or does it seem logical to someone?

(One argument for this is that you get the same unwanted output on 
loading of shared libraries on linux for instance ...)


Here is the win32 specific patch and the associated changelog.

2nd reason: It does not free the uiout struct created because I didn't find 
how to free this cleanly.


200-07-15  Pierre Muller  <muller@ics.u-strasbg.fr>

	* win32-nat.c: avoid unwanted ouptput about watchpoints on DLL loadings.
	(struct safe_symbol_file_add_args): New field uiout to store 
	previous value of global uiout variable.
	(safe_symbol_file_add_cleanup): restore uiout value.
	(safe_symbol_file_add): store uiout and create a dummy one.
	
	


$ cvs diff -u -p win32-nat.c 
Index: win32-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.60
diff -u -p -r1.60 win32-nat.c
--- win32-nat.c 11 Jul 2002 13:50:49 -0000      1.60
+++ win32-nat.c 15 Jul 2002 16:10:42 -0000
@@ -45,6 +45,9 @@
  #include <imagehlp.h>
  #include <sys/cygwin.h>

+
+#include "ui-out.h"
+#include "cli-out.h"
  #include "buildsym.h"
  #include "symfile.h"
  #include "objfiles.h"
@@ -494,6 +497,7 @@ struct safe_symbol_file_add_args
    int mainline;
    int flags;
    struct ui_file *err, *out;
+  struct ui_out *uiout;
    struct objfile *ret;
  };

@@ -534,6 +538,7 @@ safe_symbol_file_add_cleanup (void *p)
    ui_file_delete (gdb_stdout);
    gdb_stderr = sp->err;
    gdb_stdout = sp->out;
+  uiout = sp->uiout;
  #undef sp
  }

@@ -550,10 +555,12 @@ safe_symbol_file_add (char *name, int fr

    p.err = gdb_stderr;
    p.out = gdb_stdout;
+  p.uiout = uiout;
    gdb_flush (gdb_stderr);
    gdb_flush (gdb_stdout);
    gdb_stderr = ui_file_new ();
    gdb_stdout = ui_file_new ();
+  uiout = cli_out_new (gdb_stdout);
    p.name = name;
    p.from_tty = from_tty;
    p.addrs = addrs;



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: [RFC/RFA] avoid spurious Watchpoint X output on cygwin native target.

[Daniel Jacobowitz]

On Mon, Jul 15, 2002 at 06:15:01PM +0200, Pierre Muller wrote:
> 
> The following patch suppresses all 
> spurious output when a DLL is loaded in native cygwin GDB.
> 
> Its a RFC for two reasons:
> 
> First reason:
> Question:  Why do we currently get ouptut while loading a DLL
> while the safe_symbol_file_add does redefine gdb_stdout and 
> gdbstderr to dummy output exactly to suppress all output?
> 
> Answer: Because, despite gdb_stdout is redefined as a 
> dummy file does noting with the strings it gets
> (and thus is a correct way of suppressing ouptut 
> sent to gdb_stdout), the Watchpoint X...
> message is sent to uiout struct
> (see mention function in breakpoint.c source)
> The only question here is if a change of gdb_stdout should not 
> also change the global uiout variable behavior.
> This could easily be achieved by replacing 
> the stream field of the data field of ui_out struct into a 
> '** ui_file' instead of a simple '*ui_file'.
> 
>    Is that complete nonsense, or does it seem logical to someone?
> 
> (One argument for this is that you get the same unwanted output on 
> loading of shared libraries on linux for instance ...)
> 
> 
> Here is the win32 specific patch and the associated changelog.
> 
> 2nd reason: It does not free the uiout struct created because I didn't find 
> how to free this cleanly.


This is an amusing coincidence, I discovered the same thing yesterday,
working on a different patch.

I believe that uiout should write to gdb_stdout no matter what instead
of saving a stream, and that things which wish to change where output
goes should redirect gdb_stdout.  Your patch is definitely suspect,
because the current uiout might not be CLI; I don't know that it
matters for your case, although it definitely did for mine.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC/RFA] avoid spurious Watchpoint X output on cygwin native target.

[Pierre Muller]

At 18:42 15/07/2002 , Daniel Jacobowitz a écrit:
>On Mon, Jul 15, 2002 at 06:15:01PM +0200, Pierre Muller wrote:
> > 
> > The following patch suppresses all 
> > spurious output when a DLL is loaded in native cygwin GDB.
> > 
> > Its a RFC for two reasons:
> > 
> > First reason:
> > Question:  Why do we currently get ouptut while loading a DLL
> > while the safe_symbol_file_add does redefine gdb_stdout and 
> > gdbstderr to dummy output exactly to suppress all output?
> > 
> > Answer: Because, despite gdb_stdout is redefined as a 
> > dummy file does noting with the strings it gets
> > (and thus is a correct way of suppressing ouptut 
> > sent to gdb_stdout), the Watchpoint X...
> > message is sent to uiout struct
> > (see mention function in breakpoint.c source)
> > The only question here is if a change of gdb_stdout should not 
> > also change the global uiout variable behavior.
> > This could easily be achieved by replacing 
> > the stream field of the data field of ui_out struct into a 
> > '** ui_file' instead of a simple '*ui_file'.
> > 
> >    Is that complete nonsense, or does it seem logical to someone?
> > 
> > (One argument for this is that you get the same unwanted output on 
> > loading of shared libraries on linux for instance ...)
> > 
> > 
> > Here is the win32 specific patch and the associated changelog.
> > 
> > 2nd reason: It does not free the uiout struct created because I didn't find 
> > how to free this cleanly.
>
>
>This is an amusing coincidence, I discovered the same thing yesterday,
>working on a different patch.
>
>I believe that uiout should write to gdb_stdout no matter what instead
>of saving a stream, and that things which wish to change where output
>goes should redirect gdb_stdout.  Your patch is definitely suspect,
>because the current uiout might not be CLI; I don't know that it
>matters for your case, although it definitely did for mine.

   OK, if ou are working on a different way of correcting this problem, 
I am happy to withdraw my RFA and waiting for your patch !

   Isn't the suggestion above (of replacement 
of the  ui_file * into a ui_file **) 
just enough to solve the problems?



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99