Bug 29249

Probably build with more optimization? We build all targets regularly using different GCC versions, and have not seen this issue.

We may not have a working strlen this early during statically linked process startup, which is why we rely on the compiler to compute the string length for us.

Seems I'm hitting it with -Og optimizations which appears to work fine without that one commit.

I see. Which architecture do you build for, and which GCC version do you use?

We can probably avoid the strlen dependency in some other way.

Should be gcc 12.1 building for x86_64.

(In reply to James Hilliard from comment #4)
> Should be gcc 12.1 building for x86_64.

Do you just set CFLAGS="-Wall -Og -g"? Thanks.

I'll try to come up with something (along with regular testing), but probably not this week.

I think it's just -Og and -g3, although build system might be setting a few other things. I think build works fine with other optimization settings like -O2.

It's reproducible with -O1 and not reproducible with -O2 (or -O1 + -fexpensive-optimizations):

objdump -x build-x86_64-oe-linux/csu/libc-tls.o | grep _startup_fatal_not_constant

doesn't show the symbol at all with -fexpensive-optimizations, while with just -O1:

objdump -x build-x86_64-oe-linux/csu/libc-tls.o.O1 | grep _startup_fatal_not_constant
0000000000000000         *UND*  0000000000000000 _startup_fatal_not_constant
00000000000002bb R_X86_64_PLT32    _startup_fatal_not_constant-0x0000000000000004

I've tested if this is still reproducible with latest 2.36 (revision ac47d8f6cf9744139adb12f540fb9cc610cac579) and it is still reproducible, plus there is another build issue with -Og/-O1 I've reported in bug 29454

H.J can you please take a look at this one as well?

-O2 and higher works
-O1 and -Og fails

-O1 + -fexpensive-optimizations works
-Og + -fexpensive-optimizations fails

I'm aware of
https://sourceware.org/glibc/wiki/FAQ#Why_do_I_get:.60.23error_.22glibc_cannot_be_compiled_without_optimization.22.27.2C_when_trying_to_compile_GNU_libc_with_GNU_CC.3F
and use of -O0 is prevented with #error, but do we need to prevent using -O1/-Og as well?

This seems currently the only issue (now when bug 29454 was fixed, there is separate issue bug 19444 when building with -Os, patch available since 2018 in https://patchwork.ozlabs.org/project/glibc/patch/20181217213618.29538-1-Martin.Jansa@gmail.com/).

As work around this commit was already reverted in OpenEmbedded and Buildroot:
https://git.openembedded.org/openembedded-core/commit/?id=642348f9b4656a090b5a272c18a6723c60100e08
https://github.com/buildroot/buildroot/commit/8d6e07e525617ee0c4ccc4f07345b1b1a70526f7

Created attachment 14269 [details]
A patch to force -O2

Thanks H.J. Lu, I've verified that this patch works in my environment.

(In reply to Martin Jansa from comment #11)
> Thanks H.J. Lu, I've verified that this patch works in my environment.

The patch is wrong since __OPTIMIZE__ is also set to 1 for -O3 and -Ofast.

Created attachment 14283 [details]
Update TLS_INIT_TP

(In reply to H.J. Lu from comment #13)
> Created attachment 14283 [details]
> Update TLS_INIT_TP

This doesn't work for elf/rtld.c.

we hit this on arm with gcc-trunk and -O2 after a recent change.

i think TLS_INIT_TP should just indicate failure and then the caller can print a generic message. i don't think arch specific message is very important for this.

(In reply to Szabolcs Nagy from comment #15)
> we hit this on arm with gcc-trunk and -O2 after a recent change.
> 
> i think TLS_INIT_TP should just indicate failure and then the caller can
> print a generic message. i don't think arch specific message is very
> important for this.

Yeah, that's reasonable, I'll to come up with a patch.

Failure is also less likely here because of the mmap fallback we introduced.

Patch posted: https://sourceware.org/pipermail/libc-alpha/2022-November/143178.html

Fixed for 2.37 via:

commit 1f34a2328890aa192141f96449d25b77f666bf47
Author: Florian Weimer <fweimer@redhat.com>
Date:   Thu Nov 3 17:28:03 2022 +0100

    elf: Introduce <dl-call_tls_init_tp.h> and call_tls_init_tp (bug 29249)
    
    This makes it more likely that the compiler can compute the strlen
    argument in _startup_fatal at compile time, which is required to
    avoid a dependency on strlen this early during process startup.
    
    Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>