Re: [PATCH 2/4] python support for fetching separate debug files: have_debug_info

[Doug Evans <dje at google dot com>]

On Thu, Nov 20, 2014 at 11:41 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Doug Evans <dje@google.com>
>> Date: Thu, 20 Nov 2014 13:22:39 -0800
>>
>> This patch provides an API call to determine whether debug information
>> is present.  It's based on the same test that gdb internally uses
>> to decide whether to look for separate debug files.
>
> OK for the documentation parts.
>
> Btw, I wonder why this is useful, given this caveat:
>
>> +Note that a program compiled without @samp{-g} may still have some debug
>> +information, e.g., from the @code{C} runtime.  Thus a value of @code{True}
>> +for this attribute does not mean that debug information is present for
>> +every source file in the program.  It only means that debug information
>> +is present for at least one source file.
>
> If this attribute cannot be relied upon, why is it a good idea to
> expose it to Python?

It's a good question.
I thought about the name for this attribute for a non-insignificant
amount of time.
The problem that needs to be solved is for Python code to be able to tell
whether to spend time fetching separate debug files, as the latter can take
a significant amount of time.  Also, a program may use a large number of
shared libraries and the user may wish (or not wish) debug info to be
fetched for each one.  So we want, IMO, a simple and cheap initial
test for whether we need to fetch debug files.

For the use-case in question,  another way to look at the attribute is
"Has debug info been stripped or not?".
Thus one thought I had was naming it "is_stripped_debug".
The goal being to better specify the intent.  But it still has the
same problem: even if a binary didn't have debug info stripped that
doesn't mean that the desired pieces of it were compiled with -g.
Thus I went with have_debug_info.
[has_debug_info?]
I got to the point of not wanting to over-think this.

It turns out that in practice, for the use case in which this
attribute will be put, the answer it gives works well enough.
Plus providing the ability to be consistent with what gdb itself does
has value: being inconsistent can lead to confusion.

I can imagine some use-cases wanting more intelligent tests for
determining whether to put in the effort to fetch a separate debug
file  (e.g., is debug info for a particular class present).
Going this route is up to the implementer of the Python code.
What we're providing here is just building blocks.