From: Doug Evans <dje@google.com>
To: Pedro Alves <pedro@codesourcery.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
tromey@redhat.com, gdb-patches@sourceware.org
Subject: Re: [RFA] Fix too many "no debugging symbols found" warnings.
Date: Thu, 02 Jul 2009 20:08:00 -0000 [thread overview]
Message-ID: <e394668d0907021308ubd39ab9x8d990cb1be678acc@mail.gmail.com> (raw)
In-Reply-To: <200907021427.14634.pedro@codesourcery.com>
On Thu, Jul 2, 2009 at 6:27 AM, Pedro Alves<pedro@codesourcery.com> wrote:
>> executables, or anything manually done from the command line (one can
>> think of executables as falling in this category).
>
> Okay, I saw the original patch now. Let's focus on that first.
I'm not sure that's what I'd do first, but ok.
[The problem I'm trying to solve hasn't changed, I figured we'd just
focus on that.]
> This could be
> reasonable, I suppose:
>
> set print symbol-loading auto|on|off
> ^ ^ ^
> | | |
> | | +- never
> | |
> | +----- always, output even when gdb auto-loads
> |
> +-------- default, output only when gdb auto-loads
>
> although IIUC, GDB never behaved like that "on" setting, so maybe we can
> ignore that option, and think of "auto" -> "on". OTOH, the "on" above
> matches what "set verbose" does. Keep reading.
>
>[...]
> > Thirdly, symbol-loading-warnings is a compatible renaming of
> > symbol-loading [...]
>
> That's ingenious, but overboard, if you ask me. An even more compatible
> change would be to not change the command name at all.
I wouldn't categorize it as ingenious. Overboard, I dunno, it's just
an option name.
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.
>>
>> 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? If 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? Can't we
> just decide to output that latter warning under the same predicate as
> for the former "Reading..." output? It seems clear to me that it's
> formatting intent was to be always output in between
> the "from foo.so..." and "...done." bits.
>
> "Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done."
>
> That is, it was missing a "(from_tty || info_verbose)" check?
>
> Why do we need the new option for this specific warning at all?
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?
In the case of a smallish number of libraries it sounds reasonable to
me, but whatever, I can go with the flow here too. :-)
>> Put this all together and that's why the patch is the way it is.
>>
>> Ultimately, I don't have a strong opinion on having both options. I
>> do have a strong opinion on providing an option to the user to let
>> them turn off the "no debugging symbols found" message (and other such
>> messages) from automatically loaded libraries.
>
> I think we're complicating things. If GDB is *already printing something*,
> like:
>
> "Reading symbols from /lib/librt.so.1... ...done."
>
> ... then it should not be a problem for anyone to see this:
>
> "Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done."
I think that's a given, and the patch has that behavior intentionally.
> OTOH, if GDB is printing nothing, then printing a sole:
>
> "(no debugging symbols found)"
>
> out of the blue, doesn't ever seem useful to me. Is that ever really useful?
Well, s@no debugging symbols found@no debugging symbols found in
/usr/lib/libfoo.so@.
Users would like to know that something isn't going to work because
debug info is missing.
That is useful.
We could tell them differently of course. Maybe an option to "info
shared" to only show the ones without debug info or some such.
> Wouldn't tweaking the "no debugging symbols found" predicate make everyone happy?
"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?
Or something else?
next prev parent reply other threads:[~2009-07-02 20:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-23 23:24 Doug Evans
2009-05-25 3:20 ` Eli Zaretskii
2009-05-25 16:07 ` Doug Evans
2009-06-04 20:34 ` Tom Tromey
2009-06-04 21:20 ` Pedro Alves
2009-06-05 18:19 ` Tom Tromey
2009-06-05 18:49 ` Pedro Alves
2009-06-05 22:18 ` Tom Tromey
2009-06-19 0:48 ` Doug Evans
2009-06-22 17:54 ` Tom Tromey
2009-06-22 19:35 ` Pedro Alves
2009-06-30 21:49 ` Doug Evans
2009-06-30 21:55 ` Pedro Alves
2009-06-30 22:20 ` Doug Evans
2009-07-01 2:29 ` Tom Tromey
2009-07-01 3:13 ` Eli Zaretskii
2009-07-01 3:47 ` Doug Evans
2009-07-01 17:48 ` Eli Zaretskii
2009-07-01 17:53 ` Doug Evans
2009-07-01 18:01 ` Pedro Alves
2009-07-01 19:55 ` Doug Evans
2009-07-02 13:26 ` Pedro Alves
2009-07-02 20:08 ` Doug Evans [this message]
2009-07-02 22:43 ` Pedro Alves
2009-07-11 4:22 ` Doug Evans
2009-07-20 13:21 ` Pedro Alves
2009-07-23 18:57 ` Doug Evans
2009-07-27 17:15 ` Tom Tromey
2009-08-24 22:02 ` Doug Evans
2009-08-25 3:47 ` Eli Zaretskii
2009-08-27 19:11 ` Tom Tromey
2009-08-27 23:39 ` Doug Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e394668d0907021308ubd39ab9x8d990cb1be678acc@mail.gmail.com \
--to=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=pedro@codesourcery.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox