Mirage3 beta tester here. I recommend to merge this PR and make another release of Solo5. On FreeBSD, I otherwise (with solo5-kernel-virtio-0.2.0) and clang 3.9.0 (tags/RELEASE_390/final 280324):

cc -nostdlibinc -ffreestanding -mno-red-zone -isystem /usr/home/hannes/devel/mirage/solo5/include-host -std=gnu99 -Wall -Wextra -Werror -O2 -g -c malloc.c -o malloc.o
malloc.c:642:5: error: macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
#if USE_LOCKS /* Spin locks for gcc >= 4.1, older gcc on x86, MSC >= 1310 */
    ^
malloc.c:638:22: note: expanded from macro 'USE_LOCKS'
#define USE_LOCKS  ((defined(USE_SPIN_LOCKS) && USE_SPIN_LOCKS != 0) || \
                     ^
malloc.c:642:5: error: macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
malloc.c:639:22: note: expanded from macro 'USE_LOCKS'
                    (defined(USE_RECURSIVE_LOCKS) && USE_RECURSIVE_LOCKS != 0))
                     ^
malloc.c:1543:5: error: macro expansion producing 'defined' has undefined behavior
      [-Werror,-Wexpansion-to-defined]
#if USE_LOCKS
    ^
...

Can we achieve the same effect with a one line change adding

#define USE_LOCKS 0

...at the top of malloc.c where we define the other "configuration" directives?

If not, why not?

@hannesm Why haven't we run into this before? Is it something to do with a newer clang?

@mato #define USE_LOCKS 0 at the top of malloc.c works as well (compiles fine with clang-3.9). We could also put this into kernel.h and leave malloc.c untouched.

and we didn't run into this before since earlier compilation was done with clang-3.8 (3.9 was merged to FreeBSD-CURRENT at the end of November, it looks like I didn't recompile solo5 since then on my laptop). FreeBSD-11 (the latest release, I deploy my solo5 unikernels on such a machine) still uses clang 3.8.0.

Ok, that makes sense. @djwillia Can you confirm #define USE_LOCKS 0 works for you as well? If yes then I'll make that one line change and cut a new release of Solo5 at the same time.

@mato yes, #define USE_LOCKS 0 works for me as well. Is the reason you want to keep that code around because you think the code should remain as similar to stock dlmalloc as possible, or because you think we may want locks in the future, or some other reason? I had opted for removal as I feel the code is easier to read without as many nontrivial #ifdefs, and I don't think we will need locks for the foreseeable future.

@djwillia Both reasons that you mention and further: The first question that came into my mind when I read the change in isolation was "Why is this change removing the lock code rather than just turning it off, given that there's a perfectly good mechanism for the latter?"

Anyhow, thanks for acking that the one-liner works, I'll now make a new PR with that change.

Superseded by #158.