From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26978 invoked by alias); 24 Nov 2008 16:19:51 -0000 Received: (qmail 26909 invoked by uid 22791); 24 Nov 2008 16:19:49 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 24 Nov 2008 16:19:14 +0000 Received: from zps36.corp.google.com (zps36.corp.google.com [172.25.146.36]) by smtp-out.google.com with ESMTP id mAOGJ4fP025019 for ; Mon, 24 Nov 2008 08:19:04 -0800 Received: from rv-out-0506.google.com (rvbk40.prod.google.com [10.140.87.40]) by zps36.corp.google.com with ESMTP id mAOGIZqd022698 for ; Mon, 24 Nov 2008 08:19:03 -0800 Received: by rv-out-0506.google.com with SMTP id k40so2085243rvb.17 for ; Mon, 24 Nov 2008 08:19:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.106.14 with SMTP id i14mr1956840rvm.27.1227543542684; Mon, 24 Nov 2008 08:19:02 -0800 (PST) In-Reply-To: References: <18261.86.86.3.213.1227305211.squirrel@webmail.xs4all.nl> <8ac60eac0811221107s47cd5d30o472a46842a5a33ed@mail.gmail.com> Date: Mon, 24 Nov 2008 19:42:00 -0000 Message-ID: Subject: Re: too many "no debugging symbols found" messages from shared libs From: Doug Evans To: Eli Zaretskii Cc: Paul Pluzhnikov , mark.kettenis@xs4all.nl, brobecker@adacore.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-11/txt/msg00645.txt.bz2 On Sun, Nov 23, 2008 at 8:10 PM, Eli Zaretskii wrote: >> Date: Sat, 22 Nov 2008 11:07:48 -0800 >> From: Paul Pluzhnikov >> Cc: Doug Evans , mark.kettenis@xs4all.nl, brobecker@adacore.com, gdb-patches@sourceware.org >> >> On Sat, Nov 22, 2008 at 3:58 AM, Eli Zaretskii wrote: >> >> > Can we find a good way of supporting both these use cases? >> >> Any library under /lib{,64}, /usr/lib{,64} and /usr/local/lib{,64} >> is likely not an "application in development" library (although >> there are obvious exceptions to this heuristic). >> >> Another alternative: allow the user to "silence" specific >> libraries via a glob pattern, e.g. >> >> set system-library "/lib*/libc.so.6 /lib*/libpthread.so.1" >> >> The default could be "/lib* /usr/lib* /usr/local/lib*", which >> would be equivalent to the heuristic above. A user who cares >> about all libraries could reset this to "". A user who >> doesn't care about any could set this to "*". > > I'd prefer the latter method. > >> [Use ';' instead of space to separate patterns on *win* targets.] > > Yes, and Windows needs a different default for the system libraries. There's nothing in 'set system-library foo' that says it's for suppressing "no debugging symbols found" messages. I can imagine someone down the road finding another use for wanting to know what the system libraries are considered to be, but using "set system-library" will mess with the "no debugging" suppression. One could add an additional option, set print system-library-symbol-loading on|off" (or some such) akin to the current "set print symbol-loading on|off", or change the latter to "set print symbol-loading off|normal|all" (or some such, I didn't spend any time here thinking of good names :-)). [The option was added after 6.8 so we should be able to change it before the next release.] Having to specify what the system library paths are is another configuration parameter for ports, and if it's just used to suppress "no debugging symbols found", I wonder if it's worth it though.