public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Lancelot SIX <lancelot.six@amd.com>
To: <gdb-patches@sourceware.org>
Cc: <lsix@lancelotsix.com>, Lancelot SIX <lancelot.six@amd.com>
Subject: [PATCH v2 0/2] Fix regression with lazy-loading of partial symbols
Date: Thu, 19 May 2022 19:45:55 +0100	[thread overview]
Message-ID: <20220519184557.2169347-1-lancelot.six@amd.com> (raw)

This series is a V2 for https://sourceware.org/pipermail/gdb-patches/2022-April/188385.html.

Since V1:

- Instead of only changing cooked_index_functions::expand_symtabs_matching,
  change objfile so each call to a method of a quick_function is done after
  ensuring the partial symbols have been read (the exception being the methods
  used to actually read partial symbols).
- Added patch #2 which does some cleanup in
  psymbol_functions::require_partial_symbols.
- Addressed Pedro's comments regarding the testcase.

All feedback are welcome.

Best,
Lancelot.

---

The recent DWARF indexer rewrite introduced a regression when debugging
a forking program.

Here is a way to reproduce the issue (there might be other ways, but one
is enough and this one mimics the situation we encountered).  Consider a
program which forks, and the child loads a shared library and calls a
function in this shared library:

    if (fork () == 0)
      {
        void *solib = dlopen (some_solib, RTLD_NOW);
        void (*foo) () = dlsym (some_solib, "foo");
        foo ();
      }

Suppose that this program is compiled without debug info, but the shared
library it loads has debug info enabled.

When debugging such program with the following options:

  - set detach-on-fork off
  - set follow-fork-mode child

we see something like:

    (gdb) b foo
    Function "foo" not defined.
    Make breakpoint pending on future shared library load? (y or [n]) y
    Breakpoint 1 (foo) pending.
    (gdb) run
    Starting program: a.out
    [Attaching after process 19720 fork to child process 19723]
    [New inferior 2 (process 19723)]
    [Switching to process 19723]

    Thread 2.1 "a.out" hit Breakpoint 1, 0x00007ffff7fc3101 in foo () from .../libfoo.so
    (gdb) list

    Fatal signal: Segmentation fault
    ----- Backtrace -----
    [...]
    ---------------------

Lancelot SIX (2):
  gdb: Require psymtab before calling quick_functions in objfile
  gdb: Simplify psymbol_functions::require_partial_symbols

 gdb/objfiles.h                                | 10 ++++
 gdb/psymtab.c                                 |  2 +-
 gdb/symfile-debug.c                           | 30 +++++-----
 ...fork-no-detach-follow-child-dlopen-shlib.c | 23 ++++++++
 .../fork-no-detach-follow-child-dlopen.c      | 40 +++++++++++++
 .../fork-no-detach-follow-child-dlopen.exp    | 57 +++++++++++++++++++
 6 files changed, 146 insertions(+), 16 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/fork-no-detach-follow-child-dlopen-shlib.c
 create mode 100644 gdb/testsuite/gdb.base/fork-no-detach-follow-child-dlopen.c
 create mode 100644 gdb/testsuite/gdb.base/fork-no-detach-follow-child-dlopen.exp


base-commit: c4dd8eb523fae5c9d312f4b7b21377eec66e70c3
-- 
2.25.1


             reply	other threads:[~2022-05-19 18:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-19 18:45 Lancelot SIX [this message]
2022-05-19 18:45 ` [PATCH v2 1/2] gdb: Require psymtab before calling quick_functions in objfile Lancelot SIX
2022-05-20 15:51   ` Tom Tromey
2022-05-20 23:07     ` Lancelot SIX
2022-05-21  1:07       ` Tom Tromey
2022-05-19 18:45 ` [PATCH v2 2/2] gdb: Simplify psymbol_functions::require_partial_symbols Lancelot SIX
2022-05-20 15:51   ` Tom Tromey
2022-05-20 16:07   ` Simon Marchi
2022-05-20 22:55     ` [PATCH v3 2/2] gdb: Change psymbol_functions::require_partial_symbols to partial_symbols Lancelot SIX
2022-05-26 17:57       ` Tom Tromey
2022-05-26 20:42         ` Lancelot SIX

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=20220519184557.2169347-1-lancelot.six@amd.com \
    --to=lancelot.six@amd.com \
    --cc=gdb-patches@sourceware.org \
    --cc=lsix@lancelotsix.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).