diff mbox series

[v5,7/7] Make libc symbols hidden in static PIE

Message ID d7eb5cfd6953e9689c0306d808e234bd00741e6e.1611155254.git.szabolcs.nagy@arm.com
State Committed
Commit 2682695e5c7acf1e60dd3b5c3a14d4e82416262c
Headers
Series fix ifunc with static pie [BZ #27072] |

Commit Message

Szabolcs Nagy Jan. 20, 2021, 3:31 p.m. UTC 
  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.
---
 include/libc-symbols.h | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Comments

Adhemerval Zanella Jan. 21, 2021, 2:10 p.m. UTC | #1 
On 20/01/2021 12:31, Szabolcs Nagy via Libc-alpha wrote:
> 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.

Why do we need this linkage for testing? Could we fix it so this
change could be used in all static libraries?

> 
> 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.

Nice.

LGTM, thanks.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

> ---
>  include/libc-symbols.h | 9 +++++++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/include/libc-symbols.h b/include/libc-symbols.h
> index ea126ae70c..f4dd735555 100644
> --- a/include/libc-symbols.h
> +++ b/include/libc-symbols.h
> @@ -434,13 +434,18 @@ for linking")
>    strong_alias(real, name)
>  #endif
>  
> -#if defined SHARED || defined LIBC_NONSHARED \
> -  || (BUILD_PIE_DEFAULT && IS_IN (libc))
> +#if defined SHARED || defined LIBC_NONSHARED
>  # define attribute_hidden __attribute__ ((visibility ("hidden")))
>  #else
>  # define attribute_hidden
>  #endif
>  
> +/* Mark all symbols hidden in static PIE libc to avoid GOT indirections.  */
> +#if BUILD_PIE_DEFAULT && !defined NO_HIDDEN_EXTERN_FUNC_IN_PIE \
> +    && IS_IN (libc) && !defined LIBC_NONSHARED
> +# pragma GCC visibility push(hidden)
> +#endif
> +
>  #define attribute_tls_model_ie __attribute__ ((tls_model ("initial-exec")))
>  
>  #define attribute_relro __attribute__ ((section (".data.rel.ro")))
> 

Ok.
Szabolcs Nagy Jan. 21, 2021, 3:44 p.m. UTC | #2 
The 01/21/2021 11:10, Adhemerval Zanella wrote:
> On 20/01/2021 12:31, Szabolcs Nagy via Libc-alpha wrote:
> > 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.
> 
> Why do we need this linkage for testing? Could we fix it so this
> change could be used in all static libraries?

i think the md5 and sha* tests want to directly
call some internal symbol (for the hash
implementation instead of the iterated password
hash) which you can do if you static link
libcrypt.a

i don't know if this may appear in user code
(static linking some libfoo.a from libc into
a dynamic linked executable)

may be the crypt tests can be changed to be
fully static linked.
Tulio Magno Quites Machado Filho Jan. 22, 2021, 1:25 a.m. UTC | #3 
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).

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 ?? ()
Szabolcs Nagy Jan. 22, 2021, 9:41 a.m. UTC | #4 
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
Andreas Schwab Jan. 27, 2021, 9:44 a.m. UTC | #5 
This breaks every newly linked program.

Andreas.
diff mbox series

Patch

diff --git a/include/libc-symbols.h b/include/libc-symbols.h
index ea126ae70c..f4dd735555 100644
--- a/include/libc-symbols.h
+++ b/include/libc-symbols.h
@@ -434,13 +434,18 @@  for linking")
   strong_alias(real, name)
 #endif
 
-#if defined SHARED || defined LIBC_NONSHARED \
-  || (BUILD_PIE_DEFAULT && IS_IN (libc))
+#if defined SHARED || defined LIBC_NONSHARED
 # define attribute_hidden __attribute__ ((visibility ("hidden")))
 #else
 # define attribute_hidden
 #endif
 
+/* Mark all symbols hidden in static PIE libc to avoid GOT indirections.  */
+#if BUILD_PIE_DEFAULT && !defined NO_HIDDEN_EXTERN_FUNC_IN_PIE \
+    && IS_IN (libc) && !defined LIBC_NONSHARED
+# pragma GCC visibility push(hidden)
+#endif
+
 #define attribute_tls_model_ie __attribute__ ((tls_model ("initial-exec")))
 
 #define attribute_relro __attribute__ ((section (".data.rel.ro")))