Re: [PATCH] gdb: defer warnings when loading separate debug files

[Andrew Burgess <aburgess@redhat.com>]

Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> writes:

> On 12/12/22 07:15, AlexandraH á jkov á ahajkova--- via Gdb-patches wrote:
>> From: Alexandra Hájková <ahajkova@redhat.com>
>> 
>> Currently, when GDB loads debug information from a separate debug file,
>> there are a couple of warnings that could be produced if things go
>> wrong.
>> 
>> In find_separate_debug_file_by_buildid (build-id.c) GDB can give a
>> warning if the separate debug file doesn't include any actual debug
>> information, and in separate_debug_file_exists (symfile.c) we can warn
>> if the CRC checksum in the separate debug file doesn't match the
>> checksum in the original executable.
>> 
>> The problem here is that, when looking up debug information, GDB will
>> try several different approaches, lookup by build-id, lookup by
>> debug-link, and then a lookup from debuginfod.  GDB can potentially give
>> a warning from an earlier attempt, and then succeed with a later
>> attempt.  In the cases I have run into this is primarily a warning about
>> some out of date debug information on my machine, but then GDB finds the
>> correct information using debuginfod.  This can be confusing to a user,
>> they will see warnings from GDB when really everything is working just
>> fine.
>> 
>> For example:
>> warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug"
>> does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
>> 
>> This diagnostic was printed on Fedora 33 even when the correct debuginfo
>> was downloaded.
>> 
>> In this patch I propose that we defer any warnings related to looking up
>> debug information from a separate debug file.  If any of the approaches
>> are successful then GDB will not print any of the warnings.  As far as
>> the user is concerned, everything "just worked".  Only if GDB completely
>> fails to find any suitable debug information will the warnings be
>> printed.
>
> I don't really like this behavior change.  The situations you described:
>
>  - a separate debug file without any actual debug information
>  - CRC checksum that doesn't match
>
> ... are abnormal situations which still deserve being warned about, I
> think.  If the files are there, it's because they are meant to be used,
> so if something prevents GDB from using them, I want to know.

In my experience, most users don't care where the debug info comes from,
so long as GDB can find it somehow.

>                                                                Silencing
> the warning just makes investigating "why doesn't GDB read my separate
> debug file" harder.
>
> I can understand why this can be a bit confusing to the user, but
> the warning is still factually correct.  For instance, the one you
> quoted:
>
>     warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug"
>     does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
>
> This doesn't say that GDB didn't end up finding *some* debug info for
> the shared object, just that this particular one is broken.

I think we should not underestimate the concern a warning can cause.
Sure, it's not an error, but there are some users who, upon seeing a
warning, will stop and seek help until they have resolved the issue for
fear that it's important.

Maybe if we extended the warning to say "... but don't worry I found
some debug information elsewhere." then this would stop the worry?

But, I would suggest that the above message could fall into a category
below warning.  In my mind the "levels" are:

  error - something went wrong and GDB can't continue,

  warning - something went wrong, GDB can continue, but your experience
  is not going to be what you expect in some way,

  info? (this doesn't exist right now) - just some useful information,
  but everything is just fine.

The message Alexandra is changing could be an 'info' message when GDB is
able to find debug elsewhere, but could be promoted to 'warning' when
GDB is unable to find any alternative debug information.

Right now, some 'info' messages are just printed to the console by GDB,
e.g. when we print 'Reading symbols from /tmp/test...', but there are
plenty of cases where GDB doesn't print out all the intermediate steps
that it tries when looking for a result, e.g. if I do 'file ls' then GDB
will find /usr/bin/ls, but GDB doesn't tell me where it looked and
didn't find 'ls'.  I know this isn't exactly the same, but, it isn't
unrelated I think.

>                                                              Maybe it's
> an old one I installed by hand, that I should delete, maybe the package
> from the distro is broken.  In any case it's good for the user to know
> so they can fix the situation.

In my experience, in most cases, the user doesn't care about fixing the
problem, unless it is somehow stopping them debug their issue.  If GDB
can find what it needs, then I think most users don't care, things just
work, and they're fine with that.

And it's not like GDB is hiding what its doing, there are info messages
printed that GDB is downloading a file, then that GDB is reading debug
from the freshly downloaded file, so if the user does have some
expectations about which debug file should be used, this should inform
them that something isn't going quite right.

Maybe one thing we could do, which might help in this area, would be, at
the point where the (potential) warning is added to the warning list we
could emit a debug print guarded by separate_debug_file_debug.  That
way, if a user asks the question, "why is GDB failing to find the
expected debug file?", they can 'set debug separate-debug-file' and the
answer would be there?

Thanks,
Andrew