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:06:59 -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>
On 20-08-2015 23:49, Zack Weinberg wrote:
> On Thu, Aug 20, 2015 at 6:24 PM, Adhemerval Zanella
> <adhemerval.zanella@linaro.org> wrote:
>>
>> As Joseph I also support the principle of adding this new API.
>
> I am pleased to hear that.
>
>> Regarding the
>> patch some comments below. It would be better if you send it as inline instead
>> of attachment, and send on message for each patch.
>
> Regrettably, this is not a thing I can do - I have tried several mail
> clients and they all mangle patches if I put them inline.
You can easily with thunderbird (I use it) with some configurations.
>
>>> + typedef struct {char __x[__n];} __memblk;
>>> + memset (__s, 0, __n);
>>> + __asm__ ("" : : "m" (*(__memblk __attribute__ ((__may_alias__)) *)__s));
>>
>> I noted that Linux kernel uses the following definition:
>>
>> #define barrier_data(ptr) __asm__ __volatile__("": :"r"(ptr) :"memory")
>
> This is a much more aggressive optimization barrier than is necessary.
> A "memory" clobber tells the compiler that it can assume _nothing_
> about what the asm statement does to memory -- so it has to discard
> _all_ its knowledge of what's in memory where. For explicit_bzero we
> don't need to invalidate _anything_ - we just need to tell the
> compiler that certain stores may not be eliminated even though they
> appear to be dead. When we can't do that precisely, leaving
> explicit_bzero as an out-of-line function call should be more
> efficient than a whole-memory clobber.
>
> I intend to start a conversation with the GCC and LLVM people about
> adding an intrinsic that does exactly what is needed in this context,
> but I do not think that should hold up the patch.
>
> (I am not qualified to speculate on whether the kernel is also being
> too aggressive; they might be using this for completely different
> stuff.)
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).
>
>> Do we want to 'chk' version being use even for non-check?
>
> I do not understand this sentence.
My mistake here.
>
>> 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.
>
> zw
>