From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15627 invoked by alias); 24 Jul 2008 11:21:21 -0000 Received: (qmail 15616 invoked by uid 22791); 24 Jul 2008 11:21:20 -0000 X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 24 Jul 2008 11:21:03 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1KLyrn-0002ug-Uc; Thu, 24 Jul 2008 07:20:15 -0400 From: Eli Zaretskii To: "Doug Evans" CC: gdb-patches@sourceware.org In-reply-to: (dje@google.com) Subject: Re: [RFA] set print symbol-loading on|off Reply-to: Eli Zaretskii References: <20080710203701.6AF041C769A@localhost> Message-Id: Date: Thu, 24 Jul 2008 11:21:00 -0000 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00426.txt.bz2 > Date: Wed, 23 Jul 2008 15:41:08 -0700 > From: "Doug Evans" > Cc: gdb-patches@sourceware.org > > > > - printf_unfiltered (_("Reading symbols from %s..."), name); > > > - wrap_here (""); > > > - gdb_flush (gdb_stdout); > > > + if (print_symbol_loading) > > > + { > > > + printf_unfiltered (_("Reading symbols from %s..."), name); > > > + wrap_here (""); > > > + gdb_flush (gdb_stdout); > > > + } > > > > I'm not sure doing this in complete silence is a good idea. You've > > shut up GDB, but this phase could take a long time, during which GDB > > will appear to be hung. How about printing a single message, like > > "Reading symbols ..."? > > Any ideas where such a message should be printed? I'm guessing you'd want it > printed in all the user-commands that might call this lowish-level routine, > but that's just a guess. Yes, that'd be a good place. Or you could it right here, with some variable keeping track of whether this message was already printed. > Monkey-see monkey-do hacking from the "set print thread-events" patch. Any > suggestions if/how that needs to be enhanced as well? It could use a similar enhancement, yes, although it does slightly better than your original text, since it actually gives a few examples of the events to be announced. As for how to enhance it, I'd move the list of events to the detailed description, and make the list exhaustive. How does that sound? Thanks.