public inbox for libc-hacker@sourceware.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Roland McGrath <roland@redhat.com>, Ulrich Drepper <drepper@redhat.com>
Cc: Glibc hackers <libc-hacker@sources.redhat.com>
Subject: ld.so TLS problems
Date: Mon, 16 Sep 2002 06:44:00 -0000	[thread overview]
Message-ID: <20020916154413.E1013@sunsite.ms.mff.cuni.cz> (raw)

Hi!

We have a problem with errno in --with-tls ld.so:

        case R_386_TLS_TPOFF32:
          /* The offset is positive, backward from the thread pointer.  */
# ifdef RTLD_BOOTSTRAP
          *reloc_addr += map->l_tls_offset - sym->st_value;
# else
          /* We know the offset of object the symbol is contained in.
             It is a positive value which will be subtracted from the
             thread pointer.  To get the variable position in the TLS
             block we subtract the offset from that of the TLS block.  */
          if (sym != NULL)
            *reloc_addr += sym_map->l_tls_offset - sym->st_value;
# endif

This means that errno R_386_TLS_TPOFF32 .got slot is relocated
twice, without undoing what the first ld.so relocation did.
Even if _dl_rtld_map l_tls_offset is (temporarily) adjusted
for its initial l_tls_offset, I have a problem with prelink: if prelink
is to store the initial TPOFF32 reloc into ld.so, it would either
have to do REL->RELA conversion for ld.so (very bad - rela handling is
ATM #ifndef RTLD_BOOTSTRAP), or would have to be special cased for ld.so
all over prelink.

I wonder, do we really need TLS errno in ld.so?
ATM --without-tls ld.so has its private errno and __errno_location which
returns address of that variable (for all threads). Either this means
that all accesses to errno within the dynamic linker are before application
starts, or are guarded by dl_load_lock. Or it means --without-tls ld.so
is broken (as two different threads could modify/read the same errno
variable at the same time).
If the former is true, I think we should just use extern int errno attribute_hidden;
for IS_IN_rtld, otherwise we need to fix --without-tls ld.so first...

The only other TLS variable ld.so uses is __libc_tsd_DL_ERROR (but this one
for some reason doesn't use TPOFF32 ATM, will figure out what's going on).
I think that could be handled by *(GL(__libc_internal_tsd_[sg]et))().

	Jakub

                 reply	other threads:[~2002-09-16 13:44 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=20020916154413.E1013@sunsite.ms.mff.cuni.cz \
    --to=jakub@redhat.com \
    --cc=drepper@redhat.com \
    --cc=libc-hacker@sources.redhat.com \
    --cc=roland@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).