This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] explicit_bzero yet again
- From: Zack Weinberg <zackw at panix dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>
- Date: Mon, 11 Jan 2016 10:11:06 -0500
- Subject: Re: [PATCH v3] explicit_bzero yet again
- Authentication-results: sourceware.org; auth=none
- References: <564DE0BE dot 5070607 at panix dot com> <20151119155533 dot GT3818 at brightrain dot aerifal dot cx> <566593F4 dot 8040108 at panix dot com> <5665A353 dot 2080006 at arm dot com> <CAKCAbMjLfKgFGSxmjChQeBVnALDa9aEaKASYjWnQastmZTQeEg at mail dot gmail dot com> <20151229170836 dot GM25803 at vapier dot lan> <CAKCAbMgbio6M+b4uJfpUW62vmGX+Eh58=M_NOB1=DWYpoJWsVQ at mail dot gmail dot com> <20151229174511 dot GH238 at brightrain dot aerifal dot cx>
On 12/29/2015 12:45 PM, Rich Felker wrote:
> On Tue, Dec 29, 2015 at 09:22:49AM -0800, Zack Weinberg wrote:
>> On Tue, Dec 29, 2015 at 9:08 AM, Mike Frysinger <vapier@gentoo.org> wrote:
>>> On 07 Dec 2015 10:58, Zack Weinberg wrote:
>>>> glibc explicitly doesn't support being statically linked
>>>
>>> we keep it working, and we shouldn't be landing changes that explicitly break it
>>
>> Are you rejecting the patch in the absence of compiler support?
>
> I'm not calling for a rejection of the patch, but for an end to the
> claim that static linking is "not supported by glibc". It is, and it
> should work. It's probably unlikely that the code will be optimized
> out in the near future (though I haven't checked this), but I think it
> would make sense to add an extra line or two to make it semantically
> correct and safe against LTO inlining. This does not require any heavy
> "compiler support", just a compiler barrier in the form of an empty
> asm statement (with proper constraints) or similar.
I assume you mean you want the definition of explicit_bzero to be
something like this:
void explicit_bzero (void *block, size_t len)
{
memset (block, 0, len);
asm volatile ("" : : : "memory");
}
(this is a bigger barrier than strictly necessary, but, as beaten to
death elsewhere, there is no more precise construct that works in all
contexts).
What I am not clear on is whether you think it suffices to put this in
the *out-of-line* definition of explicit_bzero in libc.{so,a} (which
would mean that it only affects LTO reaching into libc.a, at least with
the current generation of compilers) or whether the headers need an
always_inline definition with the barrier (which would affect all uses).
zw