From: Eli Zaretskii <eliz@gnu.org>
To: Doug Evans <dje@google.com>
Cc: gdb-patches@sourceware.org, palves@redhat.com, sergiodj@redhat.com
Subject: Re: [PATCH 2/4] python support for fetching separate debug files: have_debug_info
Date: Sat, 22 Nov 2014 08:04:00 -0000 [thread overview]
Message-ID: <83a93ju0d7.fsf@gnu.org> (raw)
In-Reply-To: <CADPb22S8A_bwAqUF6wpShQXyBQ62M0kfdCUG2vZsNASODyN0fg@mail.gmail.com>
> Date: Fri, 21 Nov 2014 12:22:23 -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>
>
> >> 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" ?
The method, which we expose to Python programs, which fetches debug
info.
> >> 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?
I still don't understand what good will it make to have this
attribute. It seems you would like it to allow an optimization,
whereby some clever Python extension to GDB might examine this
attribute and decide not to try to fetch the debug info. But then why
not do that automatically all the time? why burden the Python
programmer with this?
next prev parent reply other threads:[~2014-11-22 8:04 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
2014-11-22 8:04 ` Eli Zaretskii [this message]
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=83a93ju0d7.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dje@google.com \
--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