From: Tom Tromey <tom@tromey.com>
To: Aaron Merey <amerey@redhat.com>
Cc: Tom Tromey <tom@tromey.com>,
Christian Biesinger via gdb-patches <gdb-patches@sourceware.org>,
Christian Biesinger <cbiesinger@google.com>
Subject: Re: [RFC PATCH] Support debuginfo and source file fetching via debuginfo server
Date: Fri, 01 Nov 2019 19:31:00 -0000 [thread overview]
Message-ID: <87sgn71ji6.fsf@tromey.com> (raw)
In-Reply-To: <CAJDtP-QFDD91iH3ste2-tvtg8BjjqdD82NJEQQ9AWYwSc=VtRg@mail.gmail.com> (Aaron Merey's message of "Mon, 28 Oct 2019 16:34:02 -0400")
Tom> The control-c question is a good one -- I'd also like to know the
Tom> answer. Most things in gdb are interruptible this way.
Aaron> We are now using the libcurl multi interface to fetch files over HTTP
Aaron> and it is mostly non-blocking (although blocking can happen during
Aaron> domain name resolution). However ctrl+c does not interrupt our symbol
Aaron> downloading within GDB. This may be due to GDB's SIGINT handling,
Aaron> which just sets a flag for the event loop when it is not safe to
Aaron> throw an exception. Based on a comment in
Aaron> gdb/event-top.c:handle_sigint(), symfile reading is one such region.
Aaron> Also, we have an environment var $DEBUGINFOD_TIMEOUT that lets users
Aaron> control how much time is spent attempting each download without having
Aaron> to rely on ctrl+c.
I think an environment variable may be too late. I realize gdb doesn't
generally allow interrupting the reading of symbol tables. But, this
case is a little different, in that the main thing happening is the
download of the debug info. Being able to interrupt this would be good,
because servers can wedge, download speeds can be low, etc. Also, maybe
printing something if the download takes too long would be good to do.
Tom
next prev parent reply other threads:[~2019-11-01 19:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 20:28 Aaron Merey
2019-09-13 21:03 ` Tom Tromey
2019-09-22 3:53 ` Christian Biesinger via gdb-patches
2019-10-09 14:55 ` Tom Tromey
2019-10-28 20:34 ` Aaron Merey
2019-11-01 19:31 ` Tom Tromey [this message]
2019-11-01 21:03 ` Aaron Merey
2019-11-02 14:05 ` Frank Ch. Eigler
2019-11-04 15:03 ` Frank Ch. Eigler
2019-11-04 15:46 ` Simon Marchi
2019-11-04 16:26 ` Frank Ch. Eigler
2019-11-05 1:59 ` Aaron Merey
2019-11-05 5:27 ` Simon Marchi
2019-11-05 10:25 ` Frank Ch. Eigler
2019-11-05 15:19 ` Simon Marchi
2019-11-05 15:50 ` Frank Ch. Eigler
2019-11-05 5:35 ` Simon Marchi
2019-11-07 23:24 ` Aaron Merey
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=87sgn71ji6.fsf@tromey.com \
--to=tom@tromey.com \
--cc=amerey@redhat.com \
--cc=cbiesinger@google.com \
--cc=gdb-patches@sourceware.org \
/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