This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] i386: Add _startup_sbrk and _startup_fatal [BZ #21913]
On Mon, Aug 7, 2017 at 12:26 PM, H.J. Lu <email@example.com> wrote:
> On Mon, Aug 7, 2017 at 6:26 AM, Zack Weinberg <firstname.lastname@example.org> wrote:
>> On Mon, Aug 7, 2017 at 9:21 AM, H.J. Lu <email@example.com> wrote:
>>> On Mon, Aug 7, 2017 at 6:11 AM, Zack Weinberg <firstname.lastname@example.org> wrote:
>>>> I presume this is to allocate memory for the TLS block. But why can't
>>>> the TLS block - remember, this is for the main thread, in a statically
>>>> linked binary - be statically allocated data?
>>> I can look into it.
> The code is
> #if TLS_TCB_AT_TP
> /* Align the TCB offset to the maximum alignment, as
> _dl_allocate_tls_storage (in elf/dl-tls.c) does using __libc_memalign
> and dl_tls_static_align. */
> tcb_offset = roundup (memsz + GL(dl_tls_static_size), max_align);
> tlsblock = __sbrk (tcb_offset + TLS_INIT_TCB_SIZE + max_align);
> #elif TLS_DTV_AT_TP
> tcb_offset = roundup (TLS_INIT_TCB_SIZE, align ?: 1);
> tlsblock = __sbrk (tcb_offset + memsz + max_align
> + TLS_PRE_TCB_SIZE + GL(dl_tls_static_size));
> tlsblock += TLS_PRE_TCB_SIZE;
> Are you suggesting that we use a static data with a fixed size and
> check the size at run-time?
This is a static binary - there should be no guessing or checking
required! The linker ought to be able to allocate the entire initial
TCB as static data. I'm surprised it doesn't already do that, in
(It might be necessary to *copy* that initial TCB onto the heap if
someone calls pthread_key_create or dlopen, but at that point malloc
>> Again, does this _need_ to happen that early, or could it be moved later?
> __libc_setup_tls should be called after ARCH_INIT_CPU_FEATURES and
<andreas> Why? </andreas>