Re: [Bug 395077] Detect that there's no debugging info

[Dodji Seketeli <dodji seketeli org>]

Hello Seemanta,

Seemanta Dutta <seemanta gmail com> writes:

> My idea was that we can implement very basic checking for debugging info
> first, and then on top of it implement a PackageKit based solution later
> on.

Ah okay.

> If I am right, a PackageKit based solution will work only for standard
> programs, right? For user created programs, the user has no option but to
> generate the elf with debugging information. Am I right?

That's correct. The PK based solution would be for when debugging
applications that are packaged into your distribution. But it can also
be for dependances of a program that you are writting yourself. E.g.,
you are debugging your pet program and at some point, you want to step
into a standard libstdc++ library call. For that, you need its debuginfo
installed. Having the debugger download these things for you could be
interesting, I believe. But it could also rather annoying if what you
want is to just debug your program quickly without having the debugger
getting on your way for that quite of things.

>
> So I propose to:
>
> 1. Implement a very basic detection system for lack of debugging info.
> 2. Later on integrate PackageKit to detect lack of debugging info *and*
> also propose downloading the debugging info, if the user wishes so.

I think this makes sense. Though, please note that with the coming
support of disassembly, we will do away with displaying messages saying
there is no debug info or what not. When we don't find the source code
for a location, we just disassemble around that location and show the
assembly to the user.

> I am planning to work on 1. first and then later on 2., i.e. develop
> PackageKit based solution. Does this approach sound good?

I think so, yes. Unless someone else has got some motivated objections,
of course. /me lurks around Jonner.

BTW, what is the state of PK support on Debian based distros?

>
> Coming to 1., well I actually did some bit of research on how to detect
> debugging info. When I run gdb on a program without debugging info, I get
> this message:
> "Reading symbols from
> /home/seemanta/Development/bin/nemiver/bin/hello...(no debugging symbols
> found)...done."
>
> Here, I wrote a 'hello world' program, which did not have any debugging
> information. My first thought is to intercept the place in nemiver where
> this message is received. I would really appreciate it if you pointed me
> to that place in the Nemiver source tree.

OK. So that output you see there is coming from the command line
interface of GDB, a.k.a. CLI. Nemiver doesn't use that command line
interface, but rather the Machine Interface, dubbed GDB/MI. The format
of the MI commands is quite well documented. On GNU/Linux distros,
typing "info GDB" lets you start reading the GDB docs. You can search
for those on the web too. In any case, there is a "GDB/MI Output Syntax"
node in the docs about the format of the MI output.

When doing a similar test than the one you did, I get this:

[dodji adjoa tests]$ gdb --interpreter=mi2 ./nodebug
~"GNU gdb (GDB) Fedora (7.0.1-46.fc12)\n"
~"Copyright (C) 2009 Free Software Foundation, Inc.\n"
~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\n"
~"This is free software: you are free to change and redistribute it.\n"
~"There is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"\n"
~"and \"show warranty\" for details.\n"
~"This GDB was configured as \"x86_64-redhat-linux-gnu\".\n"
~"For bug reporting instructions, please see:\n"
~"<http://www.gnu.org/software/gdb/bugs/>...\n"
~"\nwarning: "
~"Current output protocol does not support redirection\n"
~"Reading symbols from /home/dodji/devel/git/nemiver.git/tests/nodebug..."
~"(no debugging symbols found)...done.\n"
(gdb) 

The MI interpreter is started by providing the --interpreter=mi2 command
line parm to gdb. The nodebug program is a symplistic test program I
wrote and compiled without debug info.

You can see that there are output lines prefixed with the '~'
character. In MI parlance, each of these lines starting with '~' is
called a "console stream outpout". The MI manual says:

   [ CONSOLE-STREAM-OUTPUT is output that should be displayed as is in
     the console.  It is the textual response to a CLI command.  All
     the console output is prefixed by `~'. ]

So as you see, a console stream outpout is something that GDB can change
in any later version of GDB. Furthermore, one could think that it can
even be translated in any language (Hindi, Spanish, Ewe, whatever) if
people decide suddenly that they want the messages from the debugger in
their own language. That is why we should rather rely on proper MI
output. Unfortunately, I don't think MI properly notifies us about debug
info being loaded or not yet so the console output stuff is our only way
to go now, I am afraid.

So I think we need to catch two pieces of console output:
    1/ one that looks like "Reading symbols from <binary-file-path>"
    2/ one that looks like "(no debugging symbols foun)"

We need to match 2/ against 1/ to make sure 2/ is related to 1/ For each
binary file that is loaded. Keep in mind that the inferior could also be
linked to shared libraries, in which case we could need to keep track of
many loaded libraries.

There is an IDebugger signal that is emitted for each console
output. It's IDebugger::console_message_signal. You connect a sigc slot
to it to get notified. From there, I think you can maintain a list of
loaded librairies and some properties associated to them, like if they
have debug info or not.

Please note that there is now (in recent GDBs) an asynchronous MI
message that is emitted whenever a library is loaded. It's the
=library-loaded MI asynchronous message. It has a property that is named
"SYMBOL_LOADED" that should be 1 if debug info for that library was
loaded. Unfortunately that property is always zero at the moment. So
it's not useful. Also, Nemiver ignores that async message for now,
because it's a relatively recent addition to GDB and was not useful to
us anyway. I guess we ought to recognize it too, if we want to be
serious about tracking what library gets loaded/unloaded, and if we want
to track those libraries's property. For an example of how we parse and
use async messages, you can look for
::parse_thread_selected_async_output in nmv-gdbmi-parser.cc to see how
the =thread-selected message is handled. That should give you some
ideas.

Once you have digested this a bit, I guess we could discuss we could do
to keep track of the binaries that are loaded and their properties --
well, we are only interested in the property "debug-info-loaded" for
now, but you get my point.

-- 
Dodji Seketeli