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

[Doug Evans <dje at google dot com>]

On Fri, Nov 21, 2014 at 11:51 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 21 Nov 2014 09:33:59 -0800
>> From: Doug Evans <dje@google.com>
>> Cc: gdb-patches <gdb-patches@sourceware.org>, Pedro Alves <palves@redhat.com>,
>>       Sergio Durigan Junior <sergiodj@redhat.com>
>>
>> > 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 name is not my problem.
>
>> 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.
>
> Why not make that test part of the method that fetches the debug info?

This is Python code.  What did you mean by "method" ?

Python doesn't come with an ELF reader.
Another way we *could* go, which I kinda like, is to provide a general
purpose ELF API to Python, or try to do the bfd kind of thing and
abstract away ELF vs COFF, etc, and export that through gdb.  Then one
could determine if debug info is present that way. If I were to do the
former (the ELF API) I'd like to make it separate from gdb: why write
something only some users can use.  The latter (abstract away the file
format) has its own problems of course, but one might simplify it to
something along the lines of what libiberty/simple-object* provides.
Either of these solutions allows one to watch for a special section
pointing at separate debug info (e.g., .gnu_debuglink).

[Down the road exporting a DWARF reader to Python would be useful too,
but that's later.  If it involved providing our own libelf/libdwarf so
much the better.]

>> For the use-case in question,  another way to look at the attribute is
>> "Has debug info been stripped or not?".
>
> But there's no reliable way to determine that, either, is there?

Beyond detecting the absence of the requisite debug sections (in
dwarf: .debug_info, et.al.) ?
Or were you thinking of something else?