This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH 02/15] Initialize the stack guard earlier when linking statically.

From: Nix <nix at esperi dot org dot uk>
To: Florian Weimer <fweimer at redhat dot com>
Cc: libc-alpha at sourceware dot org
Date: Thu, 22 Dec 2016 22:38:33 +0000
Subject: Re: [PATCH 02/15] Initialize the stack guard earlier when linking statically.
Authentication-results: sourceware.org; auth=none
References: <20161219111528.14969-1-nix@esperi.org.uk> <20161219111528.14969-3-nix@esperi.org.uk> <5a33f534-3001-0741-66d2-2b19fcaab819@redhat.com> <1c236707-0c8c-2033-28b7-abc427d56942@redhat.com>

On 21 Dec 2016, Florian Weimer verbalised:

> On 12/21/2016 03:16 PM, Florian Weimer wrote:
>> I'm changing this to call __libc_setup_tls directly.  This functions is
>> in csu/ and thus automatically exempted from stack protection.  There is
>> no need to go indirectly through a definition in nptl/.

Agreed, that's much better: that indirection was always a bit nasty and
I'm glad we can do without it now. The code motion in LIBC_START_MAIN is
the delicate part, and that still looks fine.

-- 
NULL && (void)

References:
- --enable-stack-protector for glibc, v10
  - From: Nix
- [PATCH 02/15] Initialize the stack guard earlier when linking statically.
  - From: Nix
- Re: [PATCH 02/15] Initialize the stack guard earlier when linking statically.
  - From: Florian Weimer
- Re: [PATCH 02/15] Initialize the stack guard earlier when linking statically.
  - From: Florian Weimer

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]