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 v3] explicit_bzero yet again

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

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


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