This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/4] Add framework for tunables
- From: Nix <nix at esperi dot org dot uk>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: siddhesh at sourceware dot org, libc-alpha at sourceware dot org, carlos at redhat dot com
- Date: Sun, 01 Jan 2017 13:40:15 +0000
- Subject: Re: [PATCH 1/4] Add framework for tunables
- Authentication-results: sourceware.org; auth=none
- References: <1483198831-2232-1-git-send-email-siddhesh@sourceware.org> <1483198831-2232-2-git-send-email-siddhesh@sourceware.org> <8dff6c1a-cd60-47e0-c7c3-df73a7139f4d@redhat.com> <26463979-4563-d3eb-f65b-c8b7729178c9@sourceware.org> <e0d00f21-d3fe-7134-1e7c-eaf2d3743b3d@redhat.com> <ecfb268d-f850-cca5-d9b6-feb0c1767ab5@sourceware.org> <5ffd4870-bb10-e99e-2c12-4cb5437e3e07@redhat.com>
On 31 Dec 2016, Florian Weimer told this:
> On 12/31/2016 08:49 PM, Siddhesh Poyarekar wrote:
>
>>> I've also realized that the suggested csu/ move
>>> did not happen, so building with stack protector enabled could be broken.
>>
>> I saw your comment about it but did not link it to an actual suggestion.
>
> Never mind, it appears the existing magic in elf/Makefile takes care of the details.
Yeah, you never need to worry about dynamic-linker stack-protection
interactions in any directory because of that magic. It's static libc
init that poses problems for csu/, hence the hardwired disabling of the
stack-protector in csu/ for that case. (Though, as you noted in a
review, that also unfortunately catches any tests in that directory).
--
NULL && (void)