From: Doug Evans <dje@google.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches <gdb-patches@sourceware.org>,
Pedro Alves <palves@redhat.com>,
Sergio Durigan Junior <sergiodj@redhat.com>
Subject: Re: [PATCH 2/4] python support for fetching separate debug files: have_debug_info
Date: Fri, 21 Nov 2014 20:22:00 -0000 [thread overview]
Message-ID: <CADPb22S8A_bwAqUF6wpShQXyBQ62M0kfdCUG2vZsNASODyN0fg@mail.gmail.com> (raw)
In-Reply-To: <83d28gtjr5.fsf@gnu.org>
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?
next prev parent reply other threads:[~2014-11-21 20:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 21:22 Doug Evans
2014-11-21 7:41 ` Eli Zaretskii
2014-11-21 17:34 ` Doug Evans
2014-11-21 19:51 ` Eli Zaretskii
2014-11-21 20:22 ` Doug Evans [this message]
2014-11-22 8:04 ` Eli Zaretskii
2014-11-24 21:06 ` 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=CADPb22S8A_bwAqUF6wpShQXyBQ62M0kfdCUG2vZsNASODyN0fg@mail.gmail.com \
--to=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=sergiodj@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