Re: [PATCH v5 7/7] Make libc symbols hidden in static PIE

[Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org>]

The 01/21/2021 22:25, Tulio Magno Quites Machado Filho wrote:
> Szabolcs Nagy via Libc-alpha <libc-alpha@sourceware.org> writes:
> 
> > Hidden visibility can avoid indirections and RELATIVE relocs in
> > static PIE libc.
> >
> > The check should use IS_IN_LIB instead of IS_IN(libc) since all
> > symbols are defined locally in static PIE and the optimization is
> > useful in all libraries not just libc. However the test system
> > links objects from libcrypt.a into dynamic linked test binaries
> > where hidden visibility does not work.  I think mixing static and
> > shared libc components in the same binary should not be supported
> > usage, but to be safe only use hidden in libc.a.
> >
> > On some targets (i386) this optimization cannot be applied because
> > hidden visibility PIE ifunc functions don't work, so it is gated by
> > NO_HIDDEN_EXTERN_FUNC_IN_PIE.
> >
> > From -static-pie linked 'int main(){}' this shaves off 71 relative
> > relocs on aarch64 and reduces code size by about 2k.
> 
> After this patch got merged, I noticed that
> malloc/tst-malloc-stats-cancellation never returns on ppc (32-bit only).

that patch is only expected to change anything if

defined PIC && !defined SHARED && defined IS_IN(libc) && !defined LIBC_NONSHARED

i.e. when libc.a is compiled as pie.

can you check the build log e.g.

grep ' -DMODULE_NAME=libc .*-DPIC' build-and-check.log |grep -v ' -DSHARED'

should not find anything.

the backtrace e.g. can happen if malloc_stat was cancelled somehow
while the malloc lock is held and then the main thread tries to
print some error message but cannot get the malloc lock. but it is
hard to tell just from the backtrace where things went wrong.

> 
> It seems stuck in a futex_wait:
> 
> #0  0x6fddab58 in futex_wait (private=0, expected=2, futex_word=0x6ff405ec <main_arena>) at ../sysdeps/nptl/futex-internal.h:146
> #1  __lll_lock_wait_private (futex=0x6ff405ec <main_arena>) at ./lowlevellock.c:35
> #2  0x6fde3614 in __GI___libc_malloc (bytes=bytes@entry=4096) at malloc.c:3235
> #3  0x6fdbf7f0 in __GI__IO_file_doallocate (fp=0xf7dc01a0) at filedoalloc.c:101
> #4  0x6fdd6c20 in __GI__IO_doallocbuf (fp=0xf7dc01a0) at libioP.h:948
> #5  __GI__IO_doallocbuf (fp=fp@entry=0xf7dc01a0) at genops.c:342
> #6  0x6fdd5768 in _IO_new_file_overflow (f=0xf7dc01a0, ch=-1) at fileops.c:745
> #7  0x6fdd41c0 in _IO_new_file_xsputn (n=37, data=<optimized out>, f=<optimized out>) at libioP.h:948
> #8  _IO_new_file_xsputn (f=0xf7dc01a0, data=<optimized out>, n=37) at fileops.c:1197
> #9  0x6fdc19e8 in __GI__IO_fwrite (buf=0x6ffc1880, size=1, count=37, fp=0xf7dc01a0) at libioP.h:948
> #10 0x6ffc0e80 in ?? ()
> #11 0x6fd6641c in generic_start_main (main=0x6ffc0b10, argc=1, argv=0xf6c00760, auxvec=0x0, init=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>, fini=<optimized out>) at ../csu/libc-start.c:332
> #12 0x6fd665c0 in __libc_start_main (argc=<optimized out>, argv=<optimized out>, ev=<optimized out>, auxvec=<optimized out>, rtld_fini=<optimized out>, stinfo=<optimized out>, stack_on_entry=<optimized out>) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:98
> #13 0x00000000 in ?? ()
> 
> -- 
> Tulio Magno