This is the mail archive of the 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 RFC] explicit_bzero, again

On Thu, Aug 20, 2015 at 6:24 PM, Adhemerval Zanella
<> 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.

>> +  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

> Do we want to 'chk' version being use even for non-check?

I do not understand this sentence.

> 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.


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