public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: Glibc hackers <libc-hacker@sources.redhat.com>
Subject: [PATCH] Fix _dl_debug_initialize
Date: Thu, 09 Nov 2006 11:26:00 -0000	[thread overview]
Message-ID: <20061109112547.GK5868@sunsite.mff.cuni.cz> (raw)

Hi!

If ld.so is prelinked and a program is executed through ld.so
(/lib*/ld-*.so --library-path whatever /the/program) and kernel
mmaps prelink at its base address, then _r_debug.r_map is NULL.
_r_debug is initialized by _dl_debug_initialize calls.  When
invoking /the/program directly, GL(dl_ns)[ns]._ns_loaded
is initialized before first call to _dl_debug_initialize,
but when invoking program using ld.so, it is non-NULL only
on the second and following _dl_debug_initialize calls.
But at that point _r_debug.r_brk is already non-zero.
If ld.so is not prelinked or kernel mmaps it elsewhere, one of
the following _dl_debug_initialize calls will have ldbase != 0
and it will be still reinitialized.  But when rtld's l_addr
is 0 (i.e. it is mmapped at the prelinked address), _dl_debug_initialize
never reinitializes it.

We talked about splitting _dl_debug_initialize into _dl_debug_initialize
and _dl_debug_query which wouldn't initialize it, just return the
struct address, while _dl_debug_initialize would reinitialize always,
but I think that just can't work in other namespaces.

The following patch is much shorter, we simply keep reinitializing
until r_map is non-NULL.  If r->r_map is non-NULL, we know r->r_brk
is also != 0.

2006-10-09  Jakub Jelinek  <jakub@redhat.com>

	* elf/dl-debug.c (_dl_debug_initialize): Check r->r_map for 0
	rather than r->r_brk.

--- libc/elf/dl-debug.c.jj	2006-10-19 17:28:01.000000000 +0200
+++ libc/elf/dl-debug.c	2006-11-09 12:04:37.000000000 +0100
@@ -54,7 +54,7 @@ _dl_debug_initialize (ElfW(Addr) ldbase,
   else
     r = &GL(dl_ns)[ns]._ns_debug;
 
-  if (r->r_brk == 0 || ldbase != 0)
+  if (r->r_map == NULL || ldbase != 0)
     {
       /* Tell the debugger where to find the map of loaded objects.  */
       r->r_version = 1	/* R_DEBUG_VERSION XXX */;

	Jakub

                 reply	other threads:[~2006-11-09 11:26 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20061109112547.GK5868@sunsite.mff.cuni.cz \
    --to=jakub@redhat.com \
    --cc=drepper@redhat.com \
    --cc=libc-hacker@sources.redhat.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).