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)
next prev parent 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