This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH RFC] explicit_bzero, again
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 26 Aug 2015 18:34:08 -0300
- Subject: Re: [PATCH RFC] explicit_bzero, again
- Authentication-results: sourceware.org; auth=none
- References: <55C7E246 dot 3000006 at panix dot com> <55D0BDA7 dot 40402 at panix dot com> <55D653AF dot 8000107 at linaro dot org> <CAKCAbMhW4WrGYdaqiFBRYh8Vxt+5kmDb5fv7XiJ0ps1_4PA1jw at mail dot gmail dot com> <55DE2A73 dot 3060202 at linaro dot org> <CAKCAbMiaevQiDhXeJbAPNRSd7VAneQdbLZs7Ggai-Zr4oBTaHw at mail dot gmail dot com>
On 26-08-2015 18:13, Zack Weinberg wrote:
> On Wed, Aug 26, 2015 at 5:06 PM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>> On 20-08-2015 23:49, Zack Weinberg wrote:
>>> This is a much more aggressive optimization barrier than is necessary.
> ...
>> Right, but this way you are proposing limits this API to only C programs
>> and only for GNU compilers. Using kernel way to use the whole-memory
>> clobber avoids the '__memblk' (and thus compiles for C++ as well) and also
>> guarantees it works on other C compilers (clang).
>
> The *optimization* (replacing `explicit_bzero` with `memset` + vacuous
> use) is limited to C programs and GCC. The *API* works just fine
> regardless of compiler. I believe this is sufficient as a starting
> point. As and when appropriate ways to express a vacuous use become
> available in other compilers, we can add them.
Right, but do you know what kind of optimization the 'memory' cobbler avoids
and your suggestion allows? I do understand that the 'memory' cobbler is
indeed a more restrictive memory barrier, but for mostly targets avoids
a function calls were is possible is a much more gain that some memory
operations begin handle with restrictive scheduling.
>
>>>> Also I see that OpenBSD added a patch to try disable this option for LTO [1].
>>>> Do you think could it be worth to add as well in your version?
>>>
>>> I could be wrong about this, but I am fairly sure that neither GCC nor
>>> LLVM is capable of LTO-optimizing through a call to a shared library,
>>> therefore this additional complication should not be necessary.
>>
>> I agree, I was only curious if you know the background about this change.
>
> It might be necessary for a C library intended to be linked
> statically, and compiled with -flto or equivalent. That's the only
> thing I can think of. If that means glibc should have something like
> this in the !SHARED case I'm willing to add it.
I am not sure either, I will let it for future iterations (if someone found
a scenarios where it might be an issue).
>
> zw
>