RFR: 8225035: Thread stack size issue caused by large TLS size

[Thomas Stüfe]

Hi Andrew & Florian,

thanks a lot for the pointers! So I was on a completely wrong track with
pthread_setspecific.

I looked at the examples and played around with gcc and objdump and I think
I am slowly starting to get it. I also found Ulrich Dreppers TLS paper (
https://akkadia.org/drepper/tls.pdf) and a surprisingly good page from
Oracle (https://docs.oracle.com/cd/E19253-01/817-1984/chapter8-20/index.html
.

I am currently trying to find out the answer to my original question: what
- in this figure (
https://docs.oracle.com/cd/E19253-01/817-1984/6mhm7plaa/index.html#chapter8-fig-1
-
I assume that is the correct one for x64?) - is located on the thread
stack, and where.

If I understand Florian first mail correctly, the TCB is on the stack
somewhere, I assume together with the TLS segments for modules loaded at
startup? and a bit of static TLS space? I also wonder, in the picture it
seems that TLS segments for DSOs loaded later are allocated dynamically
somewhere else, does that not affect the libjvm and JNI libraries which are
both loaded via dlopen?

I will read on. Maybe I am still off track. Thanks for your help!

Cheers, Thomas

On Wed, Jun 12, 2019 at 4:43 PM Andrew Haley <aph at redhat.com> wrote:

> On 6/12/19 3:32 PM, Florian Weimer wrote:
> > I would say that static TLS has a fixed offset from the thread pointer,
> > the same in all threads, while dynamic TLS can have varying offsets
> > depending on the thread because a more complicated lookup sequence is
> > used.
>
> Quite, which is what my example showed.
>
> > You can get fixed TLS offsets in DSOs, avoiding the indirection, by
> > using the initial-exec TLS model, either via __attribute__ ((tls_model
> > ("initial-exec"))) in the source code, or via -ftls-model=initial-exec
> > on the command line.
>
>
>
> > On some targets, there is a static version of initial-exec TLS,
> > where the offset from the thread pointer is determined by the link
> > editor and put directly into the instruction stream.  This only
> > works for the main program, of course, because there can be only one
> > object in the entire program which does that.  In DSOs, you always
> > have to load the offset of a TLS variable at run time from a hidden
> > global variable initialized by the dynamic loader.
>
> ... which generates
>
> barf:
>         movq    %fs:0, %rdx
>         movq    boof at gottpoff(%rip), %rax
>         addq    %rdx, %rax
>         ret
>
> ... an example is worth a thousand words.
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>