From: Aaron Merey <amerey@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: Simon Marchi <simark@simark.ca>,
gdb-patches@sourceware.org,
Christian Biesinger <cbiesinger@google.com>
Subject: Re: [PATCH v3] Add debuginfod support to GDB
Date: Thu, 20 Feb 2020 19:55:00 -0000 [thread overview]
Message-ID: <CAJDtP-SAs_E0mx=m9Np9SY=9q0rhd19ANX6=r5oZP1cPrEJrWA@mail.gmail.com> (raw)
In-Reply-To: <871rqphwo8.fsf@tromey.com>
On Thu, Feb 20, 2020 at 2:43 PM Tom Tromey <tom@tromey.com> wrote:
> >>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> Simon> Following a discussion on IRC, I changed my mind, the simplest solution
> Simon> for now would be: when the user cancels a download, GDB will continue
> Simon> as if debug info was not available for that objfile. However, I would suggest
> Simon> printing a message saying that the download of debug info for XYZ was cancelled,
> Simon> so the user is not surprised to not have its debug info.
>
> Wouldn't this imply also clearing (or more precisely - not preserving)
> the quit flag in the interrupt case?
>
> It seems to me that as long as the interrupt is processed by the
> library, then we wouldn't want to set the quit flag again. Otherwise
> that will look like a double interrupt.
I'm going to change the interrupt handling to not preserve the quit_flag
in cases where the inferior is not running. The download will abort and
gdb will continue as if no debuginfo/source was found. If the inferior is
running and ^C happens during a download, quit_flag will be preserved
and the inferior should see ^C. If ^C happens a second time during the
download then it will abort. This will be accompanied by some help
text so the user knows what's going on. This is my understanding of
what was discussed on IRC.
Aaron
prev parent reply other threads:[~2020-02-20 19:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-07 19:27 Aaron Merey
2020-02-07 20:54 ` Simon Marchi
2020-02-10 23:51 ` Aaron Merey
2020-02-20 17:59 ` Tom Tromey
2020-02-20 18:02 ` Simon Marchi
2020-02-20 18:50 ` Simon Marchi
2020-02-20 19:43 ` Tom Tromey
2020-02-20 19:55 ` Aaron Merey [this message]
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='CAJDtP-SAs_E0mx=m9Np9SY=9q0rhd19ANX6=r5oZP1cPrEJrWA@mail.gmail.com' \
--to=amerey@redhat.com \
--cc=cbiesinger@google.com \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
--cc=tom@tromey.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