From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 800 invoked by alias); 17 Oct 2007 23:04:58 -0000 Received: (qmail 792 invoked by uid 22791); 17 Oct 2007 23:04:57 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 17 Oct 2007 23:04:55 +0000 Received: (qmail 19018 invoked from network); 17 Oct 2007 23:04:54 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Oct 2007 23:04:54 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: Unnecessary thread_db message? References: <200710171131.48034.ghost@cs.msu.su> From: Jim Blandy Date: Wed, 17 Oct 2007 23:04:00 -0000 In-Reply-To: <200710171131.48034.ghost@cs.msu.su> (Vladimir Prus's message of "Wed, 17 Oct 2007 11:31:47 +0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00126.txt.bz2 Vladimir Prus writes: > Over in linux-thread-db.c, there's code like this: > > void > check_for_thread_db (void) > { > /* First time through, report that libthread_db was successfuly > loaded. Can't print this in in thread_db_load as, at that stage, > the interpreter and it's console haven't started. */ > > if (!already_loaded) > { > printf_unfiltered (_("Using host libthread_db library \"%s\".\n"), > library); > > > The printf is totally unconditional. When gdb is started with the --quiet option, > this line is the only thing printed. The problem is that this message means nothing > to ordinary user -- he does not know what's thread_db is, and possibly has no idea > if, say, "/lib/tls/i686/cmov/libthread_db.so.1" is the right library to load. > This message seems more like debug print -- so can we print it only when some > verbose flag is set? At least. I don't think it should be printed at all --- there could be an 'info' subcommand to show this kind of information, but as you say, it's not something the user normally cares about.