Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves via Gdb-patches <gdb-patches@sourceware.org>
To: Simon Marchi <simon.marchi@polymtl.ca>,
	Florian Weimer <fweimer@redhat.com>,
	libc-alpha@sourceware.org, gdb-patches@sourceware.org
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Subject: Re: [PATCH glibc] nptl_db: different libpthread/ld.so load orders (bug 27744)
Date: Fri, 16 Apr 2021 17:25:15 +0100	[thread overview]
Message-ID: <625ec5fe-bd09-860a-f617-745042b94011@redhat.com> (raw)
In-Reply-To: <73b32cc6-e201-8bac-e442-e3dddcc01e0d@polymtl.ca>

On 16/04/21 17:07, Simon Marchi wrote:
> 
> Can this state (libpthread loaded, ld.so not loaded) really happen
> during the normal lifetime of a process?  My understanding is that this
> state happens when attaching only because GDB reads the shared libraries
> from the process in an undefined order, so libpthread may be discovered
> before ld.so.  So we present to libthread_db a state that doesn't really
> make sense.

I don't think it's random from GDB's perspective -- GDB reads the shared library
list of out of the link map, so it should be reading them in link map order.

IIRC, the order which libraries are loaded by GDB hasn't changed.  The issue
is that until recently (before glibc 1daccf403b1b), the stacks lists lived
in libpthread (stack_used/__stack_user), so the fact that GDB loaded libthread_db.so
before ld.so's symbols were loaded didn't make a difference.  Now they were moved to
ld.so, so libthread_db.so can't find them until GDB reads the ld.so symbols.
Is this assessment correct?

Pedro Alves


  parent reply	other threads:[~2021-04-16 16:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 15:56 Florian Weimer via Gdb-patches
2021-04-16 16:07 ` Simon Marchi via Gdb-patches
2021-04-16 16:12   ` Florian Weimer via Gdb-patches
2021-04-16 16:25   ` Pedro Alves via Gdb-patches [this message]
2021-04-16 16:28     ` Florian Weimer via Gdb-patches
2021-04-16 16:33       ` Pedro Alves
2021-04-16 16:43         ` Florian Weimer via Gdb-patches
2021-04-16 16:47           ` Pedro Alves via Gdb-patches
2021-04-16 16:53             ` Simon Marchi via Gdb-patches
2021-04-16 17:18               ` Pedro Alves
2021-04-16 17:26                 ` Florian Weimer via Gdb-patches
2021-04-16 17:33                 ` Simon Marchi via Gdb-patches
2021-04-16 18:29                   ` Pedro Alves
2021-04-16 18:35                   ` Florian Weimer via Gdb-patches
2021-04-16 17:28             ` Florian Weimer via Gdb-patches
2021-04-16 17:43               ` Pedro Alves
2021-04-19  9:06                 ` Florian Weimer via Gdb-patches

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=625ec5fe-bd09-860a-f617-745042b94011@redhat.com \
    --to=gdb-patches@sourceware.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=palves@redhat.com \
    --cc=simon.marchi@polymtl.ca \
    /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