Re: Help regarding exporting global variable "stack_chk_guard" for Aarch64.

["Carlos O'Donell" <carlos at redhat dot com>]

On 12/02/2013 01:41 AM, Venkataramanan Kumar wrote:
> Ref:
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02555.html
> 
> ----Snip-----
> You need to ensure that, when new glibc is built, whatever compiler it's
> built with, it continues to export the __stack_chk_guard symbol at version
> GLIBC_2.17.  Furthermore, if any released GCC version would generate
> references to __stack_chk_guard when compiling code for AArch64 with stack
> protection, you need to ensure __stack_chk_guard is a normal symbol not a
> compat symbol so that people can continue to link against new glibc when
> using old GCC.  If it's only a limited range of development versions of
> GCC that could have generated code using __stack_chk_guard because
> released versions didn't support stack protection on AArch64 at all, a
> compat symbol would probably be OK (but you should still ensure that the
> variable gets initialized with the correct value for any applications
> built with those development versions of GCC).
> -----Snip----
> 
> As you said when I set THREAD_SET_STACK_GUARD then "stack_chk_guard"
> is not exported. So I changed the export logic by introducing a new
> macro EXPORT_GLOBAL_STACK_GUARD and defined it for Aarch64.
> 
> I used that macro for exporting and setting the global
> "stack_chk_guard" to coexist with the TLS based stack guard check.
> 
> -----Snip----
> diff --git a/csu/libc-start.c b/csu/libc-start.c
> index c898d06..7479bf8 100644
> --- a/csu/libc-start.c
> +++ b/csu/libc-start.c
> @@ -32,11 +32,13 @@ extern int __libc_multiple_libcs;
>  #ifndef SHARED
>  # include <dl-osinfo.h>
>  extern void __pthread_initialize_minimal (void);
> -# ifndef THREAD_SET_STACK_GUARD
> +
> +#if !defined(THREAD_SET_STACK_GUARD) || defined(EXPORT_GLOBAL_STACK_GUARD)
>  /* Only exported for architectures that don't store the stack guard canary
>     in thread local area.  */
>  uintptr_t __stack_chk_guard attribute_relro;
> -# endif
> +#endif
> +
>  # ifndef  THREAD_SET_POINTER_GUARD
>  /* Only exported for architectures that don't store the pointer guard
>     value in thread local area.  */
> @@ -196,11 +198,13 @@ LIBC_START_MAIN (int (*main) (int, char **, char
> ** MAIN_AUXVEC_DECL),
> 
>  /* Set up the stack checker's canary.  */
>    uintptr_t stack_chk_guard = _dl_setup_stack_chk_guard (_dl_random);
> -# ifdef THREAD_SET_STACK_GUARD
> -  THREAD_SET_STACK_GUARD (stack_chk_guard);
> -# else
> +#if !defined(THREAD_SET_STACK_GUARD) || defined(EXPORT_GLOBAL_STACK_GUARD)
>    __stack_chk_guard = stack_chk_guard;
> -# endif
> +#endif
> +
> +#ifdef THREAD_SET_STACK_GUARD
> +  THREAD_SET_STACK_GUARD (stack_chk_guard);
> +#endif
> 
>    /* Set up the pointer guard value.  */
>    uintptr_t pointer_chk_guard = _dl_setup_pointer_guard (_dl_random,
> ----Snip----
> 
> Now on versioning that symbol "stack_check_guard" at Glibc 2.17, When
> I did objdump of the patched ld.so  I am getting stack_check_guard
> already versioned at glibc 2.17.
> 
> objdump -T ld.so | grep stack_chk
> 000000000002bdd0 g    DO .data.rel.ro   0000000000000008  GLIBC_2.17
> __stack_chk_guard
> 
> Should I need to add default_symbol_version and set it against GLIBC_2.17 ?
> Some pointers on versioning would help me here.

This is because the minimum symbol version for AArch64 is GLIBC_2.17.

ports/sysdeps/aarch64/shlib-versions: aarch64.*-.*-linux.*    DEFAULT                 GLIBC_2.17

Therefore you have __stack_chk_guard@@GLIBC_2.17 as the default symbol.

There is nothing else you need to do except test all the configurations
between supported and unsupported TLS-based SSP and ensure it works.

However, I'd like to see if we can avoid having a second ABI at all for
AArch64 by consigning existing code to the rubbish bin as preliminary
and unsupported which would only require a compat symbol with no
initialization or need for synchronization.

I've sent an email about that.

Cheers,
Carlos.