public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* CHECK_STATIC_TLS in R_X86_64_TPOFF64 type relocation
@ 2021-12-26 13:29 Fengkai Sun
  2021-12-26 15:48 ` Florian Weimer
  0 siblings, 1 reply; 3+ messages in thread
From: Fengkai Sun @ 2021-12-26 13:29 UTC (permalink / raw)
  To: libc-help

Hi list,

I noticed that when resolving R_X86_64_TPOFF64 type relocations, the
runtime dynamic linker would call the macro CHECK_STATIC_TLS, which can be
expanded into a call to _dl_try_allocate_static_tls. (in
sysdeps/x86_64/dl-machine.h)

The comments of _dl_try_allocate_static_tls says:

> We are trying to perform a static TLS relocation in MAP, but it was
dynamically loaded.

To the best of my knowledge, I found that R_X86_64_TPOFF64 is for
Initial-exec TLS model, which only appears in executables.

Since glibc has refused to dlopen PIEs since 2.29, why does it not see it
as an error, but still try to allocate static TLS for PIEs?

---
Thanks,
Fengkai

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CHECK_STATIC_TLS in R_X86_64_TPOFF64 type relocation
  2021-12-26 13:29 CHECK_STATIC_TLS in R_X86_64_TPOFF64 type relocation Fengkai Sun
@ 2021-12-26 15:48 ` Florian Weimer
  2021-12-27  3:05   ` Fengkai Sun
  0 siblings, 1 reply; 3+ messages in thread
From: Florian Weimer @ 2021-12-26 15:48 UTC (permalink / raw)
  To: Fengkai Sun via Libc-help; +Cc: Fengkai Sun

* Fengkai Sun via Libc-help:

>> We are trying to perform a static TLS relocation in MAP, but it was
> dynamically loaded.
>
> To the best of my knowledge, I found that R_X86_64_TPOFF64 is for
> Initial-exec TLS model, which only appears in executables.

No, initial-exec in shared objects is fine (as long as static TLS
space is available).

Local-exec TLS in executables does not need relocations, and the link
editor typically relaxes initial-exec TLS reference in main programs
to local-exec TLS, leaving no of them trace (except for the PT_TLS
segment).

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: CHECK_STATIC_TLS in R_X86_64_TPOFF64 type relocation
  2021-12-26 15:48 ` Florian Weimer
@ 2021-12-27  3:05   ` Fengkai Sun
  0 siblings, 0 replies; 3+ messages in thread
From: Fengkai Sun @ 2021-12-27  3:05 UTC (permalink / raw)
  To: Florian Weimer; +Cc: libc-help

Hi Florian,

Thanks for your reply!

I figure out that dlopened DSOs could use the initial-exec model: as long
as they can have access to static TLS, they are the same as DSOs introduced
by the main executable.

However, I am confused why (and when) the link editor emits initial-exec
for DSOs, because this model is not guaranteed to work. If the TLS segment
in a dlopened DSO is too large to fit in static space, it will fail the
main program and the user does not have a way to fix it. In contrast, the
two dynamic models always work.

Sorry if this sounds deviated and like a linker-related question.


---
Thanks,
Fengkai

On Sun, Dec 26, 2021 at 11:48 PM Florian Weimer <fw@deneb.enyo.de> wrote:

> * Fengkai Sun via Libc-help:
>
> >> We are trying to perform a static TLS relocation in MAP, but it was
> > dynamically loaded.
> >
> > To the best of my knowledge, I found that R_X86_64_TPOFF64 is for
> > Initial-exec TLS model, which only appears in executables.
>
> No, initial-exec in shared objects is fine (as long as static TLS
> space is available).
>
> Local-exec TLS in executables does not need relocations, and the link
> editor typically relaxes initial-exec TLS reference in main programs
> to local-exec TLS, leaving no of them trace (except for the PT_TLS
> segment).
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-12-27  3:05 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-26 13:29 CHECK_STATIC_TLS in R_X86_64_TPOFF64 type relocation Fengkai Sun
2021-12-26 15:48 ` Florian Weimer
2021-12-27  3:05   ` Fengkai Sun

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