From owner-freebsd-hackers@freebsd.org Wed Jul 27 09:31:37 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16185BA6997 for ; Wed, 27 Jul 2016 09:31:37 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail3.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 95A65168F for ; Wed, 27 Jul 2016 09:31:35 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 42917 invoked by uid 907); 27 Jul 2016 09:24:51 -0000 Received: from Unknown (HELO jmmacpro.tmst.com.au) (203.14.245.130) (smtp-auth username janm, mechanism plain) by mail3.transactionware.com (qpsmtpd/0.84) with (ECDHE-RSA-AES256-SHA encrypted) ESMTPSA; Wed, 27 Jul 2016 19:24:51 +1000 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: problem when compiling zfs.ko with clang with O1 on amd64 From: Jan Mikkelsen In-Reply-To: <667ac922-533f-2d37-706e-93fa9b069034@FreeBSD.org> Date: Wed, 27 Jul 2016 19:24:51 +1000 Cc: Dimitry Andric , "freebsd-hackers@freebsd.org" Message-Id: <39ABE4A1-70C6-4096-AF1D-97495F0D2BE6@transactionware.com> References: <667ac922-533f-2d37-706e-93fa9b069034@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3124) X-Mailman-Approved-At: Wed, 27 Jul 2016 11:04:52 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 09:31:37 -0000 Hi, Yes, there is serious namespace pollution in the amd64 kernel linker. = File statics are like globals but without multiple definition detection. = I find this a bit scary. See this thread for an example that affected me about a year ago: = https://docs.freebsd.org/cgi/getmsg.cgi?fetch=3D395455+0+archive/2015/free= bsd-stable/20150719.freebsd-stable = There are lots of possible silent failures here. Static functions with = the same name, as you have discovered. Static variables silently being = shared. The easiest solution I saw was decorating the local names to avoid a = clash. I started looking at it as a post kernel module link step but = couldn=E2=80=99t dedicate the time to get far enough. Regards, Jan. > On 27 Jul 2016, at 16:44, Andriy Gapon wrote: >=20 >=20 > First of all, what I describe next happens only when compiling with = -O1 > which is a non-standard option that I used to get better debugging. >=20 > So, I compile zfs module with clang on amd64 head. > Clang is: > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on > LLVM 3.8.0) >=20 > When -O1 is used I see that statements like 'T x =3D { 0 };' are > translated to calls to external memset function with the standard = arguments. >=20 > On the other hand, since recently a few ZFS source files (all hash > related: sha256c.c, sha512c.c, skein.c) have explicit calls to = memset(x, > 0, s). Those get inlined but in a particular fashion: a local memset > function is generated in each file, the function is a very thin = wrapper > around bzero and it expects the same argument as bzero. >=20 > Because of how kernel loadable modules are implemented on amd64 the > external calls to memset get resolved to the first of the local > functions. Because of the mismatch between the arguments provided and > the arguments expected the effective calls are 'bzero(x, 0)', NOPs = that is. >=20 > I am not sure if I can blame clang here. It is probably correct to > expect that it can generate a _local_ function named 'memset' without > interfering without other compilation units. However, that can be > unhelpful as we can see. >=20 > Some data: > $ nm -A --defined-only *.o | fgrep -w memset > sha256c.o:0000000000000e60 t memset > sha512c.o:00000000000010f0 t memset > skein.o:0000000000000120 t memset >=20 > $ nm /boot/kernel.z/zfs.ko | fgrep -w memset > 0000000000019030 t memset > 0000000000017e60 t memset > 0000000000019500 t memset > U memset >=20 >=20 > Assembly of one of the local memset functions: > .align 16, 0x90 > .type memset, @function >=20 > memset: > # @memset > .Lfunc_begin6: > .file 5 "/usr/src/sys/sys" "libkern.h" > .loc 5 187 0 # /usr/src/sys/sys/libkern.h:187:0 > .cfi_startproc >=20 > # BB#0: # %entry > pushq %rbp >=20 > .Ltmp105: > .cfi_def_cfa_offset 16 >=20 > .Ltmp106: > .cfi_offset %rbp, -16 > movq %rsp, %rbp >=20 > .Ltmp107: > .cfi_def_cfa_register %rbp >=20 > #DEBUG_VALUE: memset:c <- 0 > .loc 5 191 3 prologue_end # /usr/src/sys/sys/libkern.h:191:3 >=20 > .Ltmp108: > popq %rbp > jmp bzero # TAILCALL >=20 > .Ltmp109: > .Lfunc_end6: > .size memset, .Lfunc_end6-memset > .cfi_endproc >=20 >=20 > --=20 > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org"