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).