Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: "Frank Ch. Eigler" <fche@redhat.com>, 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: Mon, 04 Nov 2019 15:46:00 -0000	[thread overview]
Message-ID: <cdee1621-56dd-1779-9bc8-85c03a82561b@simark.ca> (raw)
In-Reply-To: <87bltrelab.fsf@redhat.com>

On 2019-11-04 10:03 a.m., Frank Ch. Eigler wrote:
> fche@redhat.com (Frank Ch. Eigler) writes:
> 
>> Actually we can probably do even better: trap the SIGINT ourselves in
>> libdebuginfod, but upon return to gdb with an -EINTR, the caller can
>> call set_quit_flag().  Then the rest of gdb can react the normal way.
> 
> Actually2, prototyped a solution whereby the library temporarily hijacks
> SIGINT to interrupt its ongoing transfers, then raises a SIGINT back to
> gdb or other caller upon return.  If this works, then no changes at all
> are required to the gdb/libdebuginfod interface code.
> 
> - FChe
> 

I haven't followed this thread closely, so it might be an obvious "no", but
I was wondering if the library could offer to install a callback that is call
relatively often, allowing GDB to interrupt the operation if it returns a
certain value.  GDB would check its quit_flag in there.  I would find that
cleaner and easier to understand than having the main program and libraries
competing for the same signal handler.

At the same time, that callback would be used to report progress, and GDB
could display a nice progress bar!

Simon


  reply	other threads:[~2019-11-04 15:46 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
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 [this message]
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=cdee1621-56dd-1779-9bc8-85c03a82561b@simark.ca \
    --to=simark@simark.ca \
    --cc=amerey@redhat.com \
    --cc=cbiesinger@google.com \
    --cc=fche@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --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