Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Keith Seitz <keiths@redhat.com>
To: Andrew Burgess <aburgess@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 5/5] gdb/linux: handle missing NT_FILE note when opening core files
Date: Thu, 23 Apr 2026 15:08:09 -0700	[thread overview]
Message-ID: <4ff57d97-02a3-4e10-b6f7-7203372ebda4@redhat.com> (raw)
In-Reply-To: <84829f29d55cd681c1829c60109c9eb140353795.1773498341.git.aburgess@redhat.com>

On 3/14/26 7:32 AM, Andrew Burgess wrote:
> Then in corelow.c various functions are updated in order to handle
> anonymous mappings.

Just one note below, otherwise LGTM.

> diff --git a/gdb/corelow.c b/gdb/corelow.c
> index d63dd5f8f0d..d1412c4903a 100644
> --- a/gdb/corelow.c
> +++ b/gdb/corelow.c
> @@ -1963,7 +1972,6 @@ mapped_file_info::add (const char *soname,
>   		       const bfd_build_id *build_id)
>   {
>     gdb_assert (build_id != nullptr);
> -  gdb_assert (expected_filename != nullptr);
>   
>     if (soname != nullptr)
>       {

The comment at the beginning of this method (mapped_file_info::add)
contains:

    EXPECTED_FILENAME is the name of the file that was mapped into the
    inferior as extracted from the core file, this should never be
    nullptr.

This needs to be updated, since null `expected_filename' file names
will now be ignored.

Keith

> @@ -1983,13 +1991,17 @@ mapped_file_info::add (const char *soname,
>   	m_soname_to_build_id_map[soname] = build_id;
>       }
>   
> -  /* When the core file is initially opened and the mapped files are
> -     parsed, we group the build-id information based on the file name.  As
> -     a consequence, we should see each EXPECTED_FILENAME value exactly
> -     once.  This means that each insertion should always succeed.  */
> -  const auto inserted
> -    = m_filename_to_build_id_map.emplace (expected_filename, build_id).second;
> -  gdb_assert (inserted);
> +  /* Ignore empty filenames.  */
> +  if (expected_filename != nullptr)
> +    {
> +      /* When the core file is initially opened and the mapped files are
> +	 parsed, we group the build-id information based on the file name.  As
> +	 a consequence, we should see each EXPECTED_FILENAME value exactly
> +	 once.  This means that each insertion should always succeed.  */
> +      const auto inserted
> +	= m_filename_to_build_id_map.emplace (expected_filename, build_id).second;
> +      gdb_assert (inserted);
> +    }
>   
>     /* Setup the reverse build-id to file name map.  */
>     if (actual_filename != nullptr)


  reply	other threads:[~2026-04-23 22:08 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-14 14:32 [PATCH 0/5] Improved support for core files with missing NT_FILE note Andrew Burgess
2026-03-14 14:32 ` [PATCH 1/5] gdb/testsuite: improve corefile-no-threads.py script Andrew Burgess
2026-03-14 14:32 ` [PATCH 2/5] gdb/testsuite: restructure gdb.base/corefile-buildid.exp Andrew Burgess
2026-03-14 14:32 ` [PATCH 3/5] gdb: remove 'num' argument from gdbarch_read_core_file_mappings callback Andrew Burgess
2026-03-14 14:32 ` [PATCH 4/5] gdb: remove pre-loop callback from gdbarch_read_core_file_mappings Andrew Burgess
2026-03-14 14:32 ` [PATCH 5/5] gdb/linux: handle missing NT_FILE note when opening core files Andrew Burgess
2026-04-23 22:08   ` Keith Seitz [this message]
2026-05-01 19:09     ` Andrew Burgess
2026-04-23 22:06 ` [PATCH 0/5] Improved support for core files with missing NT_FILE note Keith Seitz

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=4ff57d97-02a3-4e10-b6f7-7203372ebda4@redhat.com \
    --to=keiths@redhat.com \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /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