From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10264 invoked by alias); 16 Jul 2002 07:46:41 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10256 invoked from network); 16 Jul 2002 07:46:40 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.250) by sources.redhat.com with SMTP; 16 Jul 2002 07:46:40 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (Postfix) with ESMTP id E7379150; Tue, 16 Jul 2002 09:48:11 +0200 (CEST) Message-Id: <4.2.0.58.20020716094034.022f40e8@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr Date: Tue, 16 Jul 2002 07:24:00 -0000 To: Daniel Jacobowitz From: Pierre Muller Subject: Re: [RFC/RFA] avoid spurious Watchpoint X output on cygwin native target. Cc: gdb-patches@sources.redhat.com In-Reply-To: <20020715164212.GA22578@nevyn.them.org> References: <4.2.0.58.20020715174048.02a55688@ics.u-strasbg.fr> <4.2.0.58.20020715174048.02a55688@ics.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2002-07/txt/msg00347.txt.bz2 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