Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 3 Feb 2018 10:44:54 -0800
From:      Conrad Meyer <cem@freebsd.org>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        freebsd-bugs@freebsd.org, Brooks Davis <brooks@freebsd.org>
Subject:   Re: [Bug 225626] r325865 malloc vs bzero
Message-ID:  <CAG6CVpXxb21wZqLcspJLm%2BanJdgfV-EKhTjB1-x2rNWBMrJKBg@mail.gmail.com>
In-Reply-To: <20180203215302.T1064@besplex.bde.org>
References:  <bug-225626-8@https.bugs.freebsd.org/bugzilla/> <bug-225626-8-RsDlqNTq6z@https.bugs.freebsd.org/bugzilla/> <20180203215302.T1064@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Bruce, Brooks,

On Sat, Feb 3, 2018 at 3:52 AM, Bruce Evans <brde@optusnet.com.au> wrote:
> On Fri, 2 Feb 2018 a bug that doesn't want replies@freebsd.org wrote:
>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225626
>>
>> --- Comment #1 from Brooks Davis <brooks@FreeBSD.org> ---
> ...
>> Note that memset should be used in preference to bzero as the compiler
>> should
>> be able to elide most of the cost of the memset since it can emit it
>> inline and
>> then delete the dead stores.

(To Brooks:)
Not in -ffreestanding by default, unfortunately.  We can give it that
hint back by defining memset() in terms of __builtin_memset(), though.
We have done so for some sizes of constant bzero(), but not for bcopy,
memcpy, or memmove, unfortunately.

> Note that memset() should _not_ be used in preference to bzero() since:
> - using memset() in the kernel is a style bug, except possibly with a
> nonzero
>   fill byte
> - the existence of memset() in the kernel is an umplementation style bug,
>   except possibly with a nonzero fill byte.

This is total nonsense.

> ...
> - using memset() instead of bzero() in the kernel is a pessimization.  Since
>   memset() is only compatibilty cruft and should not be used, it is
>   intentionally not as optimized as bzero().
> ...

This can and should be fixed.

> Not so simlarly for memcpy().  Its use in the kernel is now just a style
> bug, since the compiler is not allowed to inline it (except in my version
> of course).

This should be fixed.

> ...
> FreeBSD was changed to use -ffreestanding because without it the compiler
> is allowed to inline functions like printf() and gcc started doing that
> (it converts printf(3) into puts() galore, and puts() doesn't exist in
> the kernel).  This broke all inlining, but no one cared (except me of
> course).

Isn't the other issue that non-freestanding links libgcc (GPL) into
the kernel?  We could work around puts() by adding a puts()
implementation, of course.

Conrad



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXxb21wZqLcspJLm%2BanJdgfV-EKhTjB1-x2rNWBMrJKBg>