[Bug python/32844] expose build_id of mappings in a core

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32844

--- Comment #8 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7862554bcf4fc067000f5fcead577c6f8492e8d7

commit 7862554bcf4fc067000f5fcead577c6f8492e8d7
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Thu Aug 21 09:45:18 2025 +0100

    gdb/python: introduce gdb.Corefile API

    This commit starts adding some core file related features to the
    Python API.

    In this initial commit I've tried to keep the changes as small as
    possible for easy review.

    There's a new Python class gdb.Corefile, which represents a loaded
    core file.  This API doesn't allow the user to create their own
    gdb.Corefile objects, a core file must be loaded using the 'core-file'
    command, then a gdb.Corefile object can be obtained by querying the
    inferior in which the core file was loaded.

    There's a new attribute gdb.Inferior.corefile, this is None when no
    core file is loaded, or contains a gdb.Corefile object if a core file
    has been loaded.

    Currently, the gdb.Corefile object has one attribute, and one method,
    these are:

      gdb.Corefile.filename -- the file name of the loaded core file.

      gdb.Corefile.is_valid() -- indicates if a gdb.Corefile object is
      valid or not.  See notes below.

    A gdb.Corefile object is only valid while the corresponding core file
    is loaded into an inferior.  Unloading the core file, or loading a
    different one will cause a gdb.Corefile object to become invalid.  For
    example:

      (gdb) core-file /tmp/core.54313
      ... snip ...
      (gdb) python core=gdb.selected_inferior().corefile
      (gdb) python print(core)
      <gdb.Corefile inferior=1 filename='/tmp/core.54313'>
      (gdb) python print(core.is_valid())
      True
      (gdb) core-file
      No core file now.
      (gdb) python print(core)
      <gdb.Corefile (invalid)>
      (gdb) python print(core.is_valid())
      False
      (gdb)

    In order to track changes to the core file, there is a new observable
    'core_file_changed', which accounts for the changes in corelow.c,
    observable,c, and observable.h.  Currently, this observable is not
    visible as a Python event.

    I chose to access the core file via the inferior even though the core
    file BFD object is actually stored within the program_space.  As such,
    it might seem that the natural choice would be to add the attribute as
    gdb.Progspace.corefile.

    For background reading on my choice, please see:

     
https://inbox.sourceware.org/gdb-patches/577f2c47793acb501c2611c0e6c7ea379f774830.1668789658.git.aburgess@redhat.com

    This patch was never merged, it is still on my backlog, but the
    observation in that work is that some targets are not really
    shareable.  For example, the core_target (corelow.c) stores
    information about the loaded core file within the target instance.  As
    such, each target instance represents a single loaded core file.

    Except that the BFD part of the core file is stored in the
    program_space, which is a little weird.

    During review, Tom made the observation, that maybe we should
    investigate moving the core file BFD into the core_target.  I'm
    inclined to agree with this as a direction of travel.

    All this leaves us with two observations:

      1. Currently, loading a core file into an inferior, then using
         'add-inferior' will try to share the core_target between
         inferiors.  This is broken, and can trigger GDB crashes.  The
         obvious fix, without reworking core_target, is just to prevent
         this sharing, making core_target per-inferior.

      2. Having the core file information split between the core_target
         instance, and the BFD stored in the program_space is a little
         weird, and is really just historical.  Planning for a future
         where the BFD is also stored in the core_target might be wise.

    So, if we imagine that the BFD is (one day) moved into the
    core_target, and that the core_target really becomes non-shareable,
    then it is, I think, clearer that the corefile attribute should live
    on the gdb.Inferior object, not the gdb.Progspace object.

    There's testing for all the functionality added in this commit.

    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32844

    Reviewed-By: Eli Zaretskii <eliz@gnu.org>
    Approved-By: Tom Tromey <tom@tromey.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.