public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org, Tom Tromey <tom@tromey.com>
Subject: Re: [PATCHv2 0/5] New Python hook for missing debug information
Date: Mon, 13 Nov 2023 16:04:56 +0000	[thread overview]
Message-ID: <87wmulr653.fsf@redhat.com> (raw)
In-Reply-To: <878r72sijc.fsf@tromey.com>

Tom Tromey <tom@tromey.com> writes:

>>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
>
> Andrew> This series adds a new Python hook to GDB, this hook allows a user to
> Andrew> register a handler object which will be called whenever GDB fails to
> Andrew> locate any debug information for an objfile it is loading.  These
> Andrew> handler objects can (potentially) perform host or project specific
> Andrew> actions to help GDB locate the missing debug information.
>
> Do you have some specific scenario in mind for this?  I'm wondering when
> this would be useful, and when Objfile.add_separate_debug_file wouldn't
> be sufficient.

Fedora and RHEL GDB has, for many years now, carried a local patch that
will suggest to the user a suitable RPM to install should GDB encounter
some missing debug information.

To some degree, maybe even mostly, this functionality has been replaced
by debuginfod, but there are still some situations where we're finding
this useful.

So, I'm trying to replace the RH local (C++ patch) with a Python
extension.

For RPM suggestion, Python only really need to be notified when GDB
encounters some missing debug info, and initially I did implement this
as a new event.

But when I looked at it, I didn't think this added much complexity to
core GDB, and given we don't really like to change the Python API, I
figure I might as well go with the fuller featured choice.

>
> Anyway the patches all seem fine to me.
> Approved-By: Tom Tromey <tom@tromey.com>

Thanks,
Andrew


  reply	other threads:[~2023-11-13 16:05 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 10:53 [PATCH " Andrew Burgess
2023-10-18 10:53 ` [PATCH 1/5] gdb/coffread: bring separate debug file logic into line with elfread.c Andrew Burgess
2023-10-20 17:35   ` Tom Tromey
2023-10-24 11:59     ` Andrew Burgess
2023-10-18 10:53 ` [PATCH 2/5] gdb: merge debug symbol file lookup code from coffread & elfread paths Andrew Burgess
2023-10-18 13:18   ` Jon Turney
2023-10-18 17:25     ` Andrew Burgess
2023-10-18 10:53 ` [PATCH 3/5] gdb: refactor objfile::find_and_add_separate_symbol_file Andrew Burgess
2023-10-20 17:50   ` Tom Tromey
2023-10-24 12:03     ` Andrew Burgess
2023-11-08 15:22     ` Andrew Burgess
2023-10-18 10:53 ` [PATCH 4/5] gdb: add an extension language hook for missing debug info Andrew Burgess
2023-10-18 10:53 ` [PATCH 5/5] gdb: implement missing debug handler hook for Python Andrew Burgess
2023-10-18 12:08   ` Eli Zaretskii
2023-11-08 15:48 ` [PATCHv2 0/5] New Python hook for missing debug information Andrew Burgess
2023-11-08 15:48   ` [PATCHv2 1/5] gdb/coffread: bring separate debug file logic into line with elfread.c Andrew Burgess
2023-11-08 15:48   ` [PATCHv2 2/5] gdb: merge debug symbol file lookup code from coffread & elfread paths Andrew Burgess
2023-11-08 15:48   ` [PATCHv2 3/5] gdb: refactor objfile::find_and_add_separate_symbol_file Andrew Burgess
2023-11-08 15:48   ` [PATCHv2 4/5] gdb: add an extension language hook for missing debug info Andrew Burgess
2023-11-08 15:48   ` [PATCHv2 5/5] gdb: implement missing debug handler hook for Python Andrew Burgess
2023-11-12 22:38     ` Tom Tromey
2023-11-15 12:36     ` Tom de Vries
2023-11-16 10:59       ` Andrew Burgess
2023-11-16 11:16         ` Tom de Vries
2023-11-16 17:21           ` Andrew Burgess
2023-11-16 15:26         ` Tom Tromey
2023-11-12 22:39   ` [PATCHv2 0/5] New Python hook for missing debug information Tom Tromey
2023-11-13 16:04     ` Andrew Burgess [this message]
2023-11-13 17:18       ` Tom Tromey
2023-11-12 22:40   ` Tom Tromey

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=87wmulr653.fsf@redhat.com \
    --to=aburgess@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).