Re: [PATCH] Build libc-start with stack protector for SHARED

[Siddhesh Poyarekar <siddhesh@sourceware.org>]

On 2/8/21 7:12 PM, Nix wrote:
> Is this true when -fstack-protector-all is actiev as well? That's the
> troublesome case that led to my introducing most of these
> $(no-stack-protector)s (and in general I only introduced them where I
> saw real problems).
> 
> There *are* (obviously) changes in the function prologue too when
> -fstack-protector is in use, and if there's anywhere those changes might
> really matter it's somewhere like libc-start. Are those changes safe?
> They weren't safe in the past...

The static libc-start is in fact unsafe with fstack-protector, which is 
why I enabled stack-protector only for libc-start.os and not 
libc-start.o.  In the dynamic case, the TLS initialization and stack 
canary setup ought to have already happened and using stack and if we 
see failures (which I didn't but maybe I missed the configurations 
you've tested?) then it's probably an indication of something else 
that's wrong.

Also, I checked codegen for libc-start.os with libc-start.os with 
stack-protector-strong as well as -all and found no differences compared 
to not having stack-protector enabled, which seems logical from the 
compiler standpoint since the function technically does not return.

Siddhesh