gconv module incompatibility between glibc 2.42 and glibc 2.43

[Florian Weimer]

I spent quite some time understanding this.  If you get a crash like
this on x86-64:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7dae9cf in gconv (step=0x555555555390, data=0x555555557f10, 
    inptrp=0x7fffffffd898, inend=0x7fffffffd8c0 "\2005\371\367\377\177", 
    outbufstart=0x0, irreversible=0x7fffffffd810, do_flush=0, 
    consume_incomplete=0) at ../iconv/skeleton.c:547
547		      result = DL_CALL_FCT (fct, (next_step, next_data, &outerr,
(gdb) 

It's likely a side effect of this change:

commit a5ec880f808ee7268d985bed4f961799bdc0a4bf
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date:   Fri Jun 12 13:10:10 2026 -0300

    Consolidate pointer guard to use a relro variable instead of the TCB
    
    For the targets that still read the pointer guard from the thread
    descriptor (i386, x86_64, powerpc, s390, sparc, and sh), mangle and
    demangle pointers using the module-local __pointer_chk_guard_local (in
    ld.so and static binaries) or the global __pointer_chk_guard provided by
    the dynamic loader (in shared objects), matching the scheme already used
    by aarch64, alpha, arm, csky and loongarch.
    
    On i386 the guard is no longer reachable as a single %gs-relative memory
    operand, so the assembly PTR_MANGLE/PTR_DEMANGLE PIC variants need a
    register to hold the GOT pointer and the guard address.
    
    This removes the dependency on the TCB pointer_guard slot: drop
    THREAD_{GET,SET,COPY}_POINTER_GUARD and the POINTER_GUARD tcb-offset,
    and point the POINTER_CHK_GUARD test macro at the relro variable.  The
    tcbhead_t slot is kept (renamed to an unused reserved field, except on
    s390 which reused the stack guard) to preserve the ABI.  s390 gains a
    distinct pointer guard rather than aliasing the stack guard.
    
    Checked on x86_64-linux-gnu, aarch64-linux-gnu, i686-linux-gnu, and
    armv7a-linux-gnueabihf.  I also run elf and setjmp checks on qemu
    loongarch64, powerpc64, powerpc64le, and s390x systems.
    
    Reviewed-by: DJ Delorie <dj@redhat.com>

It can happen during iconv test development if a rule like this one is
missing from iconvdata/Makefile:

$(objpfx)tst-bug33980.out: $(addprefix $(objpfx), $(gconv-modules)) \
			   $(addprefix $(objpfx),$(modules.so))

If the gconv-modules file is missing from the build tree, tests will
pick up the system gconv modules, which no longer work after the pointer
guard change.

Thanks,
Florian