Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Aaron Merey <amerey@redhat.com>, "Frank Ch. Eigler" <fche@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: Tue, 05 Nov 2019 05:27:00 -0000	[thread overview]
Message-ID: <6f3fb81a-09ef-ab07-eef4-0460181bcaa0@simark.ca> (raw)
In-Reply-To: <CAJDtP-S6DpxEGG=T01h5_O8nbYYme1+ErJhcfJEomHBm2OObKQ@mail.gmail.com>

On 2019-11-04 8:59 p.m., Aaron Merey wrote:
> On Mon, Nov 4, 2019 at 11:26 AM Frank Ch. Eigler <fche@redhat.com> wrote:
>>
>> Hi -
>>
>>> 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 [...]
>>
>> That could also work, at the cost of extending the API.  Will play with it.
>>
>> - FChE
> 
> Attached is the updated debuginfo and source lookup code, using the
> callback idea that Simon suggested. Downloads are now cancelled upon
> SIGINT and the callback can be modified with code that prints progress
> messages (the a and b parameters in the callback represent the
> numerator and denominator of the download's completion fraction).

Cool, thanks!

Maybe a user_data void pointer would be useful, to be able to get some
context in the callback?

I am noticing that debuginfod calls don't have any "context" or "handle"
parameters, which could suggest that the state of the library (if there
is any) is kept as global variables.  Is it safe to use the library to
do lookups in parallel, from different threads?  It is possible that
GDB or another program will want to do that some day.

Simon


  reply	other threads:[~2019-11-05  5:27 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
2019-11-04 16:26                 ` Frank Ch. Eigler
2019-11-05  1:59                   ` Aaron Merey
2019-11-05  5:27                     ` Simon Marchi [this message]
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=6f3fb81a-09ef-ab07-eef4-0460181bcaa0@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