From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26278 invoked by alias); 2 Jul 2009 22:43:04 -0000 Received: (qmail 26269 invoked by uid 22791); 2 Jul 2009 22:43:03 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 02 Jul 2009 22:42:54 +0000 Received: (qmail 7737 invoked from network); 2 Jul 2009 22:42:52 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Jul 2009 22:42:52 -0000 From: Pedro Alves To: Doug Evans Subject: Re: [RFA] Fix too many "no debugging symbols found" warnings. Date: Thu, 02 Jul 2009 22:43:00 -0000 User-Agent: KMail/1.9.10 Cc: Eli Zaretskii , tromey@redhat.com, gdb-patches@sourceware.org References: <20090523232414.BED2B846C2@localhost> <200907021427.14634.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907022344.12495.pedro@codesourcery.com> 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: 2009-07/txt/msg00086.txt.bz2 On Thursday 02 July 2009 21:08:22, Doug Evans wrote: > On Thu, Jul 2, 2009 at 6:27 AM, Pedro Alves wrote: > > That's ingenious, but overboard, if you ask me. An even more compatible > > change would be to not change the command name at all. >=20 > I wouldn't categorize it as ingenious. Overboard, I dunno, it's just > an option name. Maybe something in the middle? :-) Overboard in the sense that it's a scretch at trying to make backwards compatibility with an option that doesn't do the same thing. I'm of the opinion that if the previous option isn't useful at all, then we should just go with a new name for this one, no need for backwards compat with an option that not many people other than your google users=20 have had much exposure (it's not an officially released option). It kind of defeats the idea of having stable releases to have to care for such backwards compatibility. issues. > I'm not sure different levels of compatibility are at play here, > really, but ok, if you strongly want one or not want the other I can > go with the flow here. I guess I'm just of the camp that considers this a different option to the current one. Okay, I'm so close to start going with the flow too. :-) > >> > >> Fourth, gdb doesn't print symbol loading messages if (!from_tty && > >> !info_verbose). > > > > Right... > > > >> Except for the "no debugging symbols found" warning, > >> "print symbol-loading" doesn't apply unless either of those flags are > >> true (in current cvs). > > > > ... and isn't this the real problem here? =A0If we're not printing the > > "Reading symbols from foo...done." part, then we should not print the > > "no debugging symbols found" message either, ever, should we? =A0Can't = we > > just decide to output that latter warning under the same predicate as > > for the former "Reading..." output? =A0It seems clear to me that it's > > formatting intent was to be always output in between > > the "from foo.so..." and "...done." bits. > > > If that's what users want, great. > The question I have is: for the case of auto-loaded libraries do they > want the warning and otherwise have gdb stay silent? I see what you mean. If the answer to that is true, then we do want a distinct command for this. > In the case of a smallish number of libraries it sounds reasonable to > me, but whatever, I can go with the flow here too. :-) You mean, flow away? :-) > > I think we're complicating things. =A0If GDB is *already printing somet= hing*, > > like: > > > > =A0"Reading symbols from /lib/librt.so.1... ...done." > > > > ... then it should not be a problem for anyone to see this: > > > > =A0"Reading symbols from /lib/librt.so.1...(no debugging symbols found)= ...done." >=20 > I think that's a given, and the patch has that behavior intentionally. Ack. > > OTOH, if GDB is printing nothing, then printing a sole: > > > > =A0"(no debugging symbols found)" > > > > out of the blue, doesn't ever seem useful to me. =A0Is that ever really= useful? >=20 > Well, s@no debugging symbols found@no debugging symbols found in > /usr/lib/libfoo.so@. What's the output in the non-auto-loaded case, then? "Reading symbols from /lib/librt.so.1... (no debugging symbols found in /l= ib/librt.so.1) ...done." ? > Users would like to know that something isn't going to work because > debug info is missing. > That is useful. It is useful to know when a module doesn't have debug info, sure, but, that transient warning has been printed like that for years, as is, without showing the shared library name. In that state, I'm not sure how useful it has been. It appears to me we have some freedom to play with it, and when it is printed. > We could tell them differently of course. =A0Maybe an option to "info > shared" to only show the ones without debug info or some such. We do have a "Syms Read" column in info shared's output, maybe we should extend that from "Yes, No" -> "Yes, Sorry-I've-tried-but-didn't-find= -any, No". Then the user could ask GDB if it has debug info any time, instead of having to look up the log. > > Wouldn't tweaking the "no debugging symbols found" predicate make every= one happy? >=20 > "Tweaking" as in only printing "no debugging symbols found [in > /usr/lib/libfoo.so]" if (from_tty || info_verbose), and never printing > it for auto-loaded libraries? s/auto-loaded libraries/auto-loaded libraries, modules, executables, whatno= t/, yes. I'll back away from arguing now, and let you decide to do what you think is best. I don't think I'll be miserable with the change. (though with a = feeling of wrongly named option in my stomach.) --=20 Pedro Alves