From: Mark Hatle <mark.hatle@windriver.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: yocto@yoctoproject.org
Subject: Re: [prelink-cross][PATCH] Always create a conflict for R_ARM_TLS_DESC relocs
Date: Tue, 22 Jul 2014 10:56:56 -0500 [thread overview]
Message-ID: <53CE89C8.3020903@windriver.com> (raw)
In-Reply-To: <alpine.DEB.1.10.1407221529230.16254@tp.orcam.me.uk>
Thanks for the patch, I'll get it integrated later today.
(What a nasty problem for such a simple fix.)
--Mark
On 7/22/14, 9:50 AM, Maciej W. Rozycki wrote:
> Hi,
>
> This is a bit obscure. In my testing, for the purpose of upstreaming, of
> the glibc change to support ARM TLS descriptors in prelinked binaries (cf
> upstream BZ #17078, https://sourceware.org/bugzilla/show_bug.cgi?id=17078)
> I have come across a problem where all programs prelinked against glibc
> binaries using ARM TLS descriptors themselves segfaulted in the normal
> exit path, where libc.so's own TLS destructors are called. I have tracked
> it down to the GOT entry (pointed to by the DT_TLSDESC_GOT dynamic tag)
> meant to point to the lazy TLS descriptor resolver (pointed to by the
> DT_TLSDESC_PLT dynamic tag) being left uninitialised and therefore NULL.
> An attempt to call that resolver caused therefore a segfault.
>
> The cause of this lack of initialisation turned out to be an omission in
> the original fix (dated 2011-04-13 in ChangeLog.cross), that didn't ensure
> that a conflict entry is created even for these R_ARM_TLS_DESC relocations
> that refer to a local symbol. Somehow it didn't trigger in testing back
> when implemented, perhaps glibc didn't require or access the missing entry
> in code handling TLS destructors then. Such an entry is needed, because
> for prelinked binaries the DT_TLSDESC_GOT GOT entry is only initialised by
> the dynamic linker when a conflict is resolved. The change below enforces
> this conflict entry creation.
>
> This fix removes 33 failures in prelink testing with glibc built using
> ARM TLS descriptors, that is with the `-mtls-dialect=gnu2' GCC option in
> effect (that is not the default unless explicitly requested at GCC build
> time):
>
> FAIL -> PASS: default/prelink.sum:cxx1.sh
> FAIL -> PASS: default/prelink.sum:cxx2.sh
> FAIL -> PASS: default/prelink.sum:cxx3.sh
> FAIL -> PASS: default/prelink.sum:layout1.sh
> FAIL -> PASS: default/prelink.sum:layout2.sh
> FAIL -> PASS: default/prelink.sum:reloc1.sh
> FAIL -> PASS: default/prelink.sum:reloc10.sh
> FAIL -> PASS: default/prelink.sum:reloc11.sh
> FAIL -> PASS: default/prelink.sum:reloc2.sh
> FAIL -> PASS: default/prelink.sum:reloc3.sh
> FAIL -> PASS: default/prelink.sum:reloc4.sh
> FAIL -> PASS: default/prelink.sum:reloc5.sh
> FAIL -> PASS: default/prelink.sum:reloc6.sh
> FAIL -> PASS: default/prelink.sum:reloc7.sh
> FAIL -> PASS: default/prelink.sum:reloc8.sh
> FAIL -> PASS: default/prelink.sum:reloc9.sh
> FAIL -> PASS: default/prelink.sum:shuffle1.sh
> FAIL -> PASS: default/prelink.sum:shuffle2.sh
> FAIL -> PASS: default/prelink.sum:shuffle3.sh
> FAIL -> PASS: default/prelink.sum:shuffle4.sh
> FAIL -> PASS: default/prelink.sum:shuffle5.sh
> FAIL -> PASS: default/prelink.sum:shuffle6.sh
> FAIL -> PASS: default/prelink.sum:shuffle7.sh
> FAIL -> PASS: default/prelink.sum:shuffle8.sh
> FAIL -> PASS: default/prelink.sum:shuffle9.sh
> FAIL -> PASS: default/prelink.sum:tls1.sh
> FAIL -> PASS: default/prelink.sum:tls2.sh
> FAIL -> PASS: default/prelink.sum:tls3.sh
> FAIL -> PASS: default/prelink.sum:tls4.sh
> FAIL -> PASS: default/prelink.sum:tls5.sh
> FAIL -> PASS: default/prelink.sum:tls6.sh
> FAIL -> PASS: default/prelink.sum:tls7.sh
> FAIL -> PASS: default/prelink.sum:undo1.sh
>
> Please apply.
>
> 2014-07-22 Maciej W. Rozycki <macro@codesourcery.com>
>
> * src/arch-arm.c (arm_prelink_conflict_rel): Always create a
> conflict for R_ARM_TLS_DESC relocs.
> (arm_prelink_conflict_rela): Likewise.
>
> Maciej
>
> prelink-arm-tlsdesc-conflict-always.diff
> Index: trunk/src/arch-arm.c
> ===================================================================
> --- trunk.orig/src/arch-arm.c 2014-07-17 23:26:08.000000000 +0100
> +++ trunk/src/arch-arm.c 2014-07-18 04:18:53.790564615 +0100
> @@ -416,7 +416,9 @@ arm_prelink_conflict_rel (DSO *dso, stru
> case R_ARM_TLS_DTPMOD32:
> case R_ARM_TLS_TPOFF32:
> break;
> -
> + /* Likewise TLS_DESC. */
> + case R_ARM_TLS_DESC:
> + break;
> default:
> return 0;
> }
> @@ -526,7 +528,9 @@ arm_prelink_conflict_rela (DSO *dso, str
> case R_ARM_TLS_DTPMOD32:
> case R_ARM_TLS_TPOFF32:
> break;
> -
> + /* Likewise TLS_DESC. */
> + case R_ARM_TLS_DESC:
> + break;
> default:
> return 0;
> }
>
prev parent reply other threads:[~2014-07-22 15:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-22 14:50 [prelink-cross][PATCH] Always create a conflict for R_ARM_TLS_DESC relocs Maciej W. Rozycki
2014-07-22 15:56 ` Mark Hatle [this message]
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=53CE89C8.3020903@windriver.com \
--to=mark.hatle@windriver.com \
--cc=macro@codesourcery.com \
--cc=yocto@yoctoproject.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.