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: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Rich Felker <dalias at libc dot org>, GNU C Library <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>
- Date: Mon, 7 Dec 2015 10:58:32 -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>
On Mon, Dec 7, 2015 at 10:18 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 07/12/15 14:13, Zack Weinberg wrote:
>> On 11/19/2015 10:55 AM, Rich Felker wrote:
>>>
>>> Perhaps glibc explicitly does not support LTO, but with LTO this is
>>> trivially removable by the compiler. IMO from the beginning there
>>> should be asm constraints to make it impossible to remove the code
>>> even if it's inlined.
>>
>> Presently there *is* no such asm construct [...] However, presently no
>> compiler will LTO-optimize across shared library boundaries [...]
>
> obviously the concern is about static linking.
That didn't occur to me at all.
glibc explicitly doesn't support being statically linked, but I prefer
to keep it working where possible -- unfortunately, as I said, there
is no existing asm construct or compiler intrinsic that fits the bill.
I'd _like_ there to be something like
__builtin_use_memory(untyped-pointer, size) but I don't have time to
implement it myself -- this project is already way, way over the time
budget I originally allocated it -- and in any case it would only
become available in bleeding-edge compilers.
zw