From owner-freebsd-ppc@freebsd.org Sun Jan 31 01:13:26 2016 Return-Path: Delivered-To: freebsd-ppc@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 4145CA737C7 for ; Sun, 31 Jan 2016 01:13:26 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 074CC17A6 for ; Sun, 31 Jan 2016 01:13:25 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18011 invoked from network); 31 Jan 2016 01:13:22 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 01:13:22 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 30 Jan 2016 20:13:26 -0500 (EST) Received: (qmail 14172 invoked from network); 31 Jan 2016 01:13:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 01:13:25 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 88CB31C42A7; Sat, 30 Jan 2016 17:13:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 based powerpc (32 bit) buildworld runs on a PowerMac! [problems found] From: Mark Millard In-Reply-To: Date: Sat, 30 Jan 2016 17:13:21 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <2CA42792-245D-48F3-9FC7-285C52D14A6A@dsl-only.net> References: <55814789-0489-48B5-867C-F678AE4EA5FF@dsl-only.net> <20160130112913.GA7950@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 01:13:26 -0000 So far I'm unable to reproduce the problem with simple code replacing = the library code. And I expect that I have have a smoking gun for why. Care to check the = below and see if I missed something? As far as I can tell this is a = FreeBSD libc/stdio defect, not a clang 3.8.0 one. Unfortunately the reason is spread out in the code so it takes a bit to = describe the context for the uninitialized pointer that I expect is = involved. To start the description I note the actual, low-level failure point: > #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > 124 TLOOP1(*--dst =3D *--src); In the assembler code for this is the the *--src access that gets the = segmentation violation. I do not justify that claim here but use that = fact later. So what leads up to that? Going the other way, starting from the use of = snprintf. . . snprintf(char * __restrict str, size_t n, char const * __restrict fmt, = ...) sets up its __vfprintf(FILE *fp, locale_t locale, const char *fmt0, = va_list ap) use via: > va_list ap; > FILE f =3D FAKE_FILE; . . . > va_start(ap, fmt); > f._flags =3D __SWR | __SSTR; > f._bf._base =3D f._p =3D (unsigned char *)str; > f._bf._size =3D f._w =3D n; > ret =3D __vfprintf(&f, __get_locale(), fmt, ap); so at the __vfprintf call f._p reference the buffer that __vfprintf's = str references. __vfprintf in turn does (in part): > struct io_state io; /* I/O buffering state */ . . . > io_init(&io, fp); where io is on-stack (not implicitly initialized). The io_init does: > #define NIOV 8 > struct io_state { > FILE *fp; > struct __suio uio; /* output information: summary */ > struct __siov iov[NIOV];/* ... and individual io vectors */ > }; >=20 > static inline void > io_init(struct io_state *iop, FILE *fp) > { >=20 > iop->uio.uio_iov =3D iop->iov; > iop->uio.uio_resid =3D 0; > iop->uio.uio_iovcnt =3D 0; > iop->fp =3D fp; > } where (on stack as part of __vfprintf's io): > struct __siov { > void *iov_base; > size_t iov_len; > }; > struct __suio { > struct __siov *uio_iov; > int uio_iovcnt; > int uio_resid; > }; So via __vfprintf's io.fp->_p the str buffer is accessible for = outputting to. But in none of this or other code that I've looked at for this snprintf = use case have I found code that initializes the involved = io.uio.uio_iov->iov_base (i.e., io.iov[0].iov_base) to point to anything = specific. (Nor is iov_base's matching iov_len initialized.) Here is a stab at finding all the initializations of iov_base fields: > # grep "iov_base.*=3D" /usr/src/lib/libc/stdio/* > /usr/src/lib/libc/stdio/fputs.c: iov.iov_base =3D (void *)s; > /usr/src/lib/libc/stdio/fputws.c: iov.iov_base =3D buf; > /usr/src/lib/libc/stdio/fwrite.c: iov.iov_base =3D (void *)buf; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D (char = *)s; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D ": "; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D msgbuf; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D "\n"; > /usr/src/lib/libc/stdio/printfcommon.h: = iop->iov[iop->uio.uio_iovcnt].iov_base =3D (char *)ptr; > /usr/src/lib/libc/stdio/puts.c: iov[0].iov_base =3D (void *)s; > /usr/src/lib/libc/stdio/puts.c: iov[1].iov_base =3D "\n"; > /usr/src/lib/libc/stdio/putw.c: iov.iov_base =3D &w; > /usr/src/lib/libc/stdio/vfwprintf.c: iov.iov_base =3D buf; > /usr/src/lib/libc/stdio/xprintf.c: io->iovp->iov_base =3D = __DECONST(void *, ptr); The only file above involved in common for this context turns out to be: = /usr/src/lib/libc/stdio/printfcommon.h and the above assignment in that = file is in io_print(struct io_state *iop, const CHAR * __restrict ptr, = int len, locale_t locale), which is not in use for this context. Here is = the assignment anyway (for reference): > static inline int > io_print(struct io_state *iop, const CHAR * __restrict ptr, int len, = locale_t locale) > { >=20 > iop->iov[iop->uio.uio_iovcnt].iov_base =3D (char *)ptr; > iop->iov[iop->uio.uio_iovcnt].iov_len =3D len; > iop->uio.uio_resid +=3D len; . . . In other words: The segmentation violation is for use of __vfprintf's = uninitialized io.uio.uio_iov->iov_base . Returning to tracing the actually used code for this context to support = that claim some more. . . The __vfprintf (FILE *fp, locale_t locale, const char *fmt0, va_list ap) = eventually does: if (io_flush(&io, locale)) and io_flush(struct io_state *iop, locale_t locale) does: return (__sprint(iop->fp, &iop->uio, locale)); and _sprintf(FILE *fp, struct __suio *uio, locale_t locale) does: err =3D __sfvwrite(fp, uio); and __sfvwrite(FILE *fp, struct __suio *uio) does: p =3D iov->iov_base; len =3D iov->iov_len; where iov->iov_base is another name for __vfprintf's = io.uio.uio_iov->iov_base . __sfvwrite then uses: #define COPY(n) (void)memcpy((void *)fp->_p, (void *)p, (size_t)(n)) which fails dereferencing p (i.e., __vfprintf's io.uio.uio_iov->iov_base = ).=20 In other words (again): The segmentation violation is for use of the = uninitialized iop->uio.uio_iov->iov_base. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 5:58 AM, Mark Millard wrote: On 2016-Jan-30, at 3:29 AM, Roman Divacky wrote: > Can you file a bug in llvm bugzilla? I could try for the example code. But I'd like to make the example more = self contained first, avoiding snprintf from library code and hopefully = with a much smaller, simpler implementation involved than the = very-general library code. Separately: I'm not sure any llvm folks are going to have a way to test = unless someone shows the problem outside a FreeBSD context. = powerpc-clang (32-bit) based FreeBSD buildworld's are not exactly a = normal context at this point. My files with powerpc (32-bit) tied differences from svn for = projects/clang380-import -r294962 are: Index: /media/usr/src/sys/boot/powerpc/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/boot/powerpc/Makefile (revision 294962) +++ /media/usr/src/sys/boot/powerpc/Makefile (working copy) @@ -1,5 +1,9 @@ # $FreeBSD$ -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot +SUBDIR=3D boot1.chrp +.if ${MACHINE_ARCH} =3D=3D "powerpc64" +SUBDIR+=3D kboot +.endif +SUBDIR+=3D ofw ps3 uboot .include Index: /media/usr/src/sys/conf/Makefile.powerpc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/Makefile.powerpc (revision 294962) +++ /media/usr/src/sys/conf/Makefile.powerpc (working copy) @@ -35,7 +35,11 @@ INCLUDES+=3D -I$S/contrib/libfdt +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -msoft-float -Wa,-many +.else +CFLAGS+=3D -msoft-float +.endif # Build position-independent kernel CFLAGS+=3D -fPIC Index: /media/usr/src/sys/conf/kern.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/kern.mk (revision 294962) +++ /media/usr/src/sys/conf/kern.mk (working copy) @@ -144,7 +144,11 @@ # .if ${MACHINE_CPUARCH} =3D=3D "powerpc" CFLAGS+=3D -mno-altivec +.if ${COMPILER_TYPE} =3D=3D "clang" && ${COMPILER_VERSION} < 30800 CFLAGS.clang+=3D -mllvm -disable-ppc-float-in-variadic=3Dtrue +.else +CFLAGS.clang+=3D -msoft-float +.endif CFLAGS.gcc+=3D -msoft-float INLINE_LIMIT?=3D 15000 .endif Index: /media/usr/src/sys/conf/kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/kmod.mk (revision 294962) +++ /media/usr/src/sys/conf/kmod.mk (working copy) @@ -137,8 +137,12 @@ .endif .if ${MACHINE_CPUARCH} =3D=3D powerpc +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+=3D -fno-omit-frame-pointer .endif +.endif .if ${MACHINE_CPUARCH} =3D=3D mips CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls (I can not actually buildkernel for powerpc via clang 3.8.0. Still some = of the above is for the kernel context.) src.conf content: KERNCONF=3DGENERICvtsc-NODEBUG TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc # WITH_FAST_DEPEND=3D WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D # # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITHOUT_LIB32=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D On Sat, Jan 30, 2016 at 03:00:26AM -0800, Mark Millard wrote: > I got around to trying some more use of the 3.8.0 clang based world on = powerpc (32 bit) (now -r294962 based) and ran into: >=20 > A) Segmentation faults during signal handlers in syslogd, nfsd, = mountd, and (for SIGNFO) make. >=20 > B) ls sometimes segmentation faulting >=20 > C) make -j 6 buildworld segmentation faulting in make eventually but = make buildworld works. >=20 > I have reduced (A) to a simple program that demonstrates the behavior: >=20 >> # more sig_snprintf_use_test.c=20 >> #include >> #include >>=20 >> volatile sig_atomic_t sat =3D 0; >>=20 >> void >> handler(int sig) >> { >> char uidbuf[32]; >> (void) snprintf(uidbuf, sizeof uidbuf, "%d", 10); >> sat =3D uidbuf[0]; >> } >>=20 >> int >> main(void) >> { >> if (signal(SIGINT, handler) !=3D SIG_ERR) raise(SIGINT); >> return sat; >> } >=20 >> # ./a.out >> Segmentation fault (core dumped) >> # /usr/local/bin/gdb a.out /var/crash/a.out.1510.core >> GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD] > . . . >> warning: Unexpected size of section `.reg2/100167' in core file. >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> 124 TLOOP1(*--dst =3D *--src); >> (gdb) bt >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> #1 0x419a3984 in __sfvwrite (fp=3D, uio=3D) at /usr/src/lib/libc/stdio/fvwrite.c:128 >> #2 0x41934468 in __sprint (fp=3D, uio=3D, locale=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:164 >> #3 io_flush (iop=3D, locale=3D) at = /usr/src/lib/libc/stdio/printfcommon.h:155 >> #4 __vfprintf (fp=3D, locale=3D, = fmt0=3D, ap=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:1020 >> #5 0x4199c644 in snprintf (str=3D0xffffd734 "", n=3D, = fmt=3D0x1800850 "%d") at /usr/src/lib/libc/stdio/snprintf.c:72 >> #6 0x01800708 in handler () >> Backtrace stopped: Cannot access memory at address 0xffffd760 >=20 > (The "Unexpected size . . ." is a known problem in powerpc land at = this point, not tied to clang 3.8.0 .) >=20 > The syslogd, nfsd, mountd, and SIGINFO-related make backtraces are = similar. I got the program above from simplifying the mountd failure = context. >=20 > A direct call, handler(0), does not get the segmentation fault. >=20 > I'll note that in C the handler calling snprintf or other such is a = no-no for the general case: only abort(), _Exit(), or signal() as of C99 = as I understand. But the restriction is not true of use of raise so the = small program is still valid C99 code. Of course it appears FreeBSD = allows more than C99 does in this area. >=20 > I've not yet investigated what the original signals are in syslogd, = nfsd, or mountd. They may well indicate another problem. >=20 >=20 > I've not gotten as far classifying (B) or (C) as well. >=20 > (B) is a xo_emit context each time so far (so C elipsis use again, = like (A)) but no signal handler seems to be active. It stops in = xo_format_string_direct. My attempts at simpler code have not produced = the problem so far. >=20 > (C) is such that GDB 7.10 reports "previous frame to this frame = (corrupt stack?)" or otherwise gives up. It shows Var_Value called by = Make_Update before reporting that. gdb 6.1.1 shows more after that: = JobFinish, JobReapChild, Job_CatchChildern, Job_CatchOutput, Make_Run, = main). SIGCHLD or other such use may well be involved here. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-19, at 2:35 AM, Mark Millard wrote: >=20 > I now have an SSD that contains: >=20 > 0) installkernel material from a gcc 4.2.1 based buildkernel >=20 > 1) installworld material from a clang 3.8.0 based buildworld > (clang 3.8.0, libc++, etc.) >=20 > It boots and seems to be operating fine after booting --in both a G5 = and a G4 PowerMac. >=20 > Apparently the clang code generation has been updated to not require = an explicit -mlongcall. I had to remove those since clang rejects them = on command lines. It linked without complaint (and later seems to be = running fine). (I've seen llvm review notes mentioning the "medium = model" or some phrase like that for powerpc.) >=20 > (I've not been able to buildkernel yet for powerpc (non-64) from my = amd64 environment: rejected command lines for other issues. Thus the = current limitation to buildworld.) >=20 >=20 >=20 > To get to (1) I did the following sort of sequence: > (The first few steps deal with other issues in order to have = sufficient context.) >=20 >=20 > A) Started by installing the latest powerpc (non-64) snapshot. > ( = http://ftp1.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0= -CURRENT-powerpc-20160113-r293801-disc1.iso ) >=20 > (I had to use a PowerMac with video hardware that vt would handle.) > (Basic display, no X-windows involvement here.) >=20 >=20 > B) Rebuild, including using my usual kernel configuration that has > both vt and sc. I did this based on projects/clang380-import > -r294201 /usr/src but still using gcc 4.2.1 (native on the > PowerMac). The configuration turns off kernel debugging extras too. >=20 >=20 > C) installkernel, installworld, etc., set to use sc instead of vt, and = rebooted. >=20 > (As of this I could use the SSD in more PowerMacs by using sc instead = of vt via a /boot/loader.conf assignment.) >=20 >=20 > D) dump/restore the file systems to another SSD (after partitioning = it). > Adjust the host name and the like on the copy. >=20 > (This copy later ends up having new installworld materials overlaid.) >=20 >=20 > E) In a projects/clang380-import -r294201 amd64 environment, = buildworld for > TARGET_ARCH=3Dpowerpc . WITH_LIBCPLUSPLUS=3D and clang related = material built, > gcc 4.2.1 related material not built. WITH_BOOT=3D as well. I choose > WITHOUT_DEBUG=3D and WITHOUT_DEBUG_FILES=3D . (I've not tried enabling = them yet.) > binutils is not from ports. >=20 >=20 > F) Use DESTDIR=3D with installworld to an initially empty directory = tree. tar the tree. >=20 >=20 > G) Transfer the tar file to the PowerMac. Mount the to-be-updated SSD = to > /mnt and /mnt/var. After chflags -R noschg on /mnt and /mnt/var use > tar xpf to replace things from the buildworld on /mnt and /mnt/var. >=20 > (This does leave older gcc 4.2.1 related materials in place.) >=20 > H) Dismounts, shutdown, and then boot from the updated SSD. >=20 >=20 >=20 > Note: I've never manage to get powerpc64-xtoolchain-gcc/powerpc64-gcc = to produce working 32-bit code. So I've never gotten this far via that = path. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Jan 31 01:59:24 2016 Return-Path: Delivered-To: freebsd-ppc@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 D5D72A743B3 for ; Sun, 31 Jan 2016 01:59:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 92BB477E for ; Sun, 31 Jan 2016 01:59:24 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30631 invoked from network); 31 Jan 2016 01:59:23 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 01:59:23 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 30 Jan 2016 20:59:18 -0500 (EST) Received: (qmail 28181 invoked from network); 31 Jan 2016 01:59:18 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 01:59:18 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 033321C43D8; Sat, 30 Jan 2016 17:59:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 based powerpc (32 bit) buildworld runs on a PowerMac! [problems found] From: Mark Millard In-Reply-To: <2CA42792-245D-48F3-9FC7-285C52D14A6A@dsl-only.net> Date: Sat, 30 Jan 2016 17:59:21 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <55814789-0489-48B5-867C-F678AE4EA5FF@dsl-only.net> <20160130112913.GA7950@vlakno.cz> <2CA42792-245D-48F3-9FC7-285C52D14A6A@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 01:59:25 -0000 I have submitted a minor variation of this analysis text for the = uninitialized pointer use in in libc/stdio "string output" routine = implementations as Bug 206770. If anyone finds that I missed the initialization let me know and I'll = change the status of the bug. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 5:13 PM, Mark Millard wrote: So far I'm unable to reproduce the problem with simple code replacing = the library code. And I expect that I have have a smoking gun for why. Care to check the = below and see if I missed something? As far as I can tell this is a = FreeBSD libc/stdio defect, not a clang 3.8.0 one. Unfortunately the reason is spread out in the code so it takes a bit to = describe the context for the uninitialized pointer that I expect is = involved. To start the description I note the actual, low-level failure point: > #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > 124 TLOOP1(*--dst =3D *--src); In the assembler code for this is the the *--src access that gets the = segmentation violation. I do not justify that claim here but use that = fact later. So what leads up to that? Going the other way, starting from the use of = snprintf. . . snprintf(char * __restrict str, size_t n, char const * __restrict fmt, = ...) sets up its __vfprintf(FILE *fp, locale_t locale, const char *fmt0, = va_list ap) use via: > va_list ap; > FILE f =3D FAKE_FILE; . . . > va_start(ap, fmt); > f._flags =3D __SWR | __SSTR; > f._bf._base =3D f._p =3D (unsigned char *)str; > f._bf._size =3D f._w =3D n; > ret =3D __vfprintf(&f, __get_locale(), fmt, ap); so at the __vfprintf call f._p reference the buffer that __vfprintf's = str references. __vfprintf in turn does (in part): > struct io_state io; /* I/O buffering state */ . . . > io_init(&io, fp); where io is on-stack (not implicitly initialized). The io_init does: > #define NIOV 8 > struct io_state { > FILE *fp; > struct __suio uio; /* output information: summary */ > struct __siov iov[NIOV];/* ... and individual io vectors */ > }; >=20 > static inline void > io_init(struct io_state *iop, FILE *fp) > { >=20 > iop->uio.uio_iov =3D iop->iov; > iop->uio.uio_resid =3D 0; > iop->uio.uio_iovcnt =3D 0; > iop->fp =3D fp; > } where (on stack as part of __vfprintf's io): > struct __siov { > void *iov_base; > size_t iov_len; > }; > struct __suio { > struct __siov *uio_iov; > int uio_iovcnt; > int uio_resid; > }; So via __vfprintf's io.fp->_p the str buffer is accessible for = outputting to. But in none of this or other code that I've looked at for this snprintf = use case have I found code that initializes the involved = io.uio.uio_iov->iov_base (i.e., io.iov[0].iov_base) to point to anything = specific. (Nor is iov_base's matching iov_len initialized.) Here is a stab at finding all the initializations of iov_base fields: > # grep "iov_base.*=3D" /usr/src/lib/libc/stdio/* > /usr/src/lib/libc/stdio/fputs.c: iov.iov_base =3D (void *)s; > /usr/src/lib/libc/stdio/fputws.c: iov.iov_base =3D buf; > /usr/src/lib/libc/stdio/fwrite.c: iov.iov_base =3D (void *)buf; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D (char = *)s; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D ": "; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D msgbuf; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D "\n"; > /usr/src/lib/libc/stdio/printfcommon.h: = iop->iov[iop->uio.uio_iovcnt].iov_base =3D (char *)ptr; > /usr/src/lib/libc/stdio/puts.c: iov[0].iov_base =3D (void *)s; > /usr/src/lib/libc/stdio/puts.c: iov[1].iov_base =3D "\n"; > /usr/src/lib/libc/stdio/putw.c: iov.iov_base =3D &w; > /usr/src/lib/libc/stdio/vfwprintf.c: iov.iov_base =3D buf; > /usr/src/lib/libc/stdio/xprintf.c: io->iovp->iov_base =3D = __DECONST(void *, ptr); The only file above involved in common for this context turns out to be: = /usr/src/lib/libc/stdio/printfcommon.h and the above assignment in that = file is in io_print(struct io_state *iop, const CHAR * __restrict ptr, = int len, locale_t locale), which is not in use for this context. Here is = the assignment anyway (for reference): > static inline int > io_print(struct io_state *iop, const CHAR * __restrict ptr, int len, = locale_t locale) > { >=20 > iop->iov[iop->uio.uio_iovcnt].iov_base =3D (char *)ptr; > iop->iov[iop->uio.uio_iovcnt].iov_len =3D len; > iop->uio.uio_resid +=3D len; . . . In other words: The segmentation violation is for use of __vfprintf's = uninitialized io.uio.uio_iov->iov_base . Returning to tracing the actually used code for this context to support = that claim some more. . . The __vfprintf (FILE *fp, locale_t locale, const char *fmt0, va_list ap) = eventually does: if (io_flush(&io, locale)) and io_flush(struct io_state *iop, locale_t locale) does: return (__sprint(iop->fp, &iop->uio, locale)); and _sprintf(FILE *fp, struct __suio *uio, locale_t locale) does: err =3D __sfvwrite(fp, uio); and __sfvwrite(FILE *fp, struct __suio *uio) does: p =3D iov->iov_base; len =3D iov->iov_len; where iov->iov_base is another name for __vfprintf's = io.uio.uio_iov->iov_base . __sfvwrite then uses: #define COPY(n) (void)memcpy((void *)fp->_p, (void *)p, (size_t)(n)) which fails dereferencing p (i.e., __vfprintf's io.uio.uio_iov->iov_base = ).=20 In other words (again): The segmentation violation is for use of the = uninitialized iop->uio.uio_iov->iov_base. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 5:58 AM, Mark Millard wrote: On 2016-Jan-30, at 3:29 AM, Roman Divacky wrote: > Can you file a bug in llvm bugzilla? I could try for the example code. But I'd like to make the example more = self contained first, avoiding snprintf from library code and hopefully = with a much smaller, simpler implementation involved than the = very-general library code. Separately: I'm not sure any llvm folks are going to have a way to test = unless someone shows the problem outside a FreeBSD context. = powerpc-clang (32-bit) based FreeBSD buildworld's are not exactly a = normal context at this point. My files with powerpc (32-bit) tied differences from svn for = projects/clang380-import -r294962 are: Index: /media/usr/src/sys/boot/powerpc/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/boot/powerpc/Makefile (revision 294962) +++ /media/usr/src/sys/boot/powerpc/Makefile (working copy) @@ -1,5 +1,9 @@ # $FreeBSD$ -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot +SUBDIR=3D boot1.chrp +.if ${MACHINE_ARCH} =3D=3D "powerpc64" +SUBDIR+=3D kboot +.endif +SUBDIR+=3D ofw ps3 uboot .include Index: /media/usr/src/sys/conf/Makefile.powerpc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/Makefile.powerpc (revision 294962) +++ /media/usr/src/sys/conf/Makefile.powerpc (working copy) @@ -35,7 +35,11 @@ INCLUDES+=3D -I$S/contrib/libfdt +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -msoft-float -Wa,-many +.else +CFLAGS+=3D -msoft-float +.endif # Build position-independent kernel CFLAGS+=3D -fPIC Index: /media/usr/src/sys/conf/kern.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/kern.mk (revision 294962) +++ /media/usr/src/sys/conf/kern.mk (working copy) @@ -144,7 +144,11 @@ # .if ${MACHINE_CPUARCH} =3D=3D "powerpc" CFLAGS+=3D -mno-altivec +.if ${COMPILER_TYPE} =3D=3D "clang" && ${COMPILER_VERSION} < 30800 CFLAGS.clang+=3D -mllvm -disable-ppc-float-in-variadic=3Dtrue +.else +CFLAGS.clang+=3D -msoft-float +.endif CFLAGS.gcc+=3D -msoft-float INLINE_LIMIT?=3D 15000 .endif Index: /media/usr/src/sys/conf/kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/kmod.mk (revision 294962) +++ /media/usr/src/sys/conf/kmod.mk (working copy) @@ -137,8 +137,12 @@ .endif .if ${MACHINE_CPUARCH} =3D=3D powerpc +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+=3D -fno-omit-frame-pointer .endif +.endif .if ${MACHINE_CPUARCH} =3D=3D mips CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls (I can not actually buildkernel for powerpc via clang 3.8.0. Still some = of the above is for the kernel context.) src.conf content: KERNCONF=3DGENERICvtsc-NODEBUG TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc # WITH_FAST_DEPEND=3D WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D # # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITHOUT_LIB32=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D On Sat, Jan 30, 2016 at 03:00:26AM -0800, Mark Millard wrote: > I got around to trying some more use of the 3.8.0 clang based world on = powerpc (32 bit) (now -r294962 based) and ran into: >=20 > A) Segmentation faults during signal handlers in syslogd, nfsd, = mountd, and (for SIGNFO) make. >=20 > B) ls sometimes segmentation faulting >=20 > C) make -j 6 buildworld segmentation faulting in make eventually but = make buildworld works. >=20 > I have reduced (A) to a simple program that demonstrates the behavior: >=20 >> # more sig_snprintf_use_test.c=20 >> #include >> #include >>=20 >> volatile sig_atomic_t sat =3D 0; >>=20 >> void >> handler(int sig) >> { >> char uidbuf[32]; >> (void) snprintf(uidbuf, sizeof uidbuf, "%d", 10); >> sat =3D uidbuf[0]; >> } >>=20 >> int >> main(void) >> { >> if (signal(SIGINT, handler) !=3D SIG_ERR) raise(SIGINT); >> return sat; >> } >=20 >> # ./a.out >> Segmentation fault (core dumped) >> # /usr/local/bin/gdb a.out /var/crash/a.out.1510.core >> GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD] > . . . >> warning: Unexpected size of section `.reg2/100167' in core file. >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> 124 TLOOP1(*--dst =3D *--src); >> (gdb) bt >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> #1 0x419a3984 in __sfvwrite (fp=3D, uio=3D) at /usr/src/lib/libc/stdio/fvwrite.c:128 >> #2 0x41934468 in __sprint (fp=3D, uio=3D, locale=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:164 >> #3 io_flush (iop=3D, locale=3D) at = /usr/src/lib/libc/stdio/printfcommon.h:155 >> #4 __vfprintf (fp=3D, locale=3D, = fmt0=3D, ap=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:1020 >> #5 0x4199c644 in snprintf (str=3D0xffffd734 "", n=3D, = fmt=3D0x1800850 "%d") at /usr/src/lib/libc/stdio/snprintf.c:72 >> #6 0x01800708 in handler () >> Backtrace stopped: Cannot access memory at address 0xffffd760 >=20 > (The "Unexpected size . . ." is a known problem in powerpc land at = this point, not tied to clang 3.8.0 .) >=20 > The syslogd, nfsd, mountd, and SIGINFO-related make backtraces are = similar. I got the program above from simplifying the mountd failure = context. >=20 > A direct call, handler(0), does not get the segmentation fault. >=20 > I'll note that in C the handler calling snprintf or other such is a = no-no for the general case: only abort(), _Exit(), or signal() as of C99 = as I understand. But the restriction is not true of use of raise so the = small program is still valid C99 code. Of course it appears FreeBSD = allows more than C99 does in this area. >=20 > I've not yet investigated what the original signals are in syslogd, = nfsd, or mountd. They may well indicate another problem. >=20 >=20 > I've not gotten as far classifying (B) or (C) as well. >=20 > (B) is a xo_emit context each time so far (so C elipsis use again, = like (A)) but no signal handler seems to be active. It stops in = xo_format_string_direct. My attempts at simpler code have not produced = the problem so far. >=20 > (C) is such that GDB 7.10 reports "previous frame to this frame = (corrupt stack?)" or otherwise gives up. It shows Var_Value called by = Make_Update before reporting that. gdb 6.1.1 shows more after that: = JobFinish, JobReapChild, Job_CatchChildern, Job_CatchOutput, Make_Run, = main). SIGCHLD or other such use may well be involved here. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-19, at 2:35 AM, Mark Millard wrote: >=20 > I now have an SSD that contains: >=20 > 0) installkernel material from a gcc 4.2.1 based buildkernel >=20 > 1) installworld material from a clang 3.8.0 based buildworld > (clang 3.8.0, libc++, etc.) >=20 > It boots and seems to be operating fine after booting --in both a G5 = and a G4 PowerMac. >=20 > Apparently the clang code generation has been updated to not require = an explicit -mlongcall. I had to remove those since clang rejects them = on command lines. It linked without complaint (and later seems to be = running fine). (I've seen llvm review notes mentioning the "medium = model" or some phrase like that for powerpc.) >=20 > (I've not been able to buildkernel yet for powerpc (non-64) from my = amd64 environment: rejected command lines for other issues. Thus the = current limitation to buildworld.) >=20 >=20 >=20 > To get to (1) I did the following sort of sequence: > (The first few steps deal with other issues in order to have = sufficient context.) >=20 >=20 > A) Started by installing the latest powerpc (non-64) snapshot. > ( = http://ftp1.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0= -CURRENT-powerpc-20160113-r293801-disc1.iso ) >=20 > (I had to use a PowerMac with video hardware that vt would handle.) > (Basic display, no X-windows involvement here.) >=20 >=20 > B) Rebuild, including using my usual kernel configuration that has > both vt and sc. I did this based on projects/clang380-import > -r294201 /usr/src but still using gcc 4.2.1 (native on the > PowerMac). The configuration turns off kernel debugging extras too. >=20 >=20 > C) installkernel, installworld, etc., set to use sc instead of vt, and = rebooted. >=20 > (As of this I could use the SSD in more PowerMacs by using sc instead = of vt via a /boot/loader.conf assignment.) >=20 >=20 > D) dump/restore the file systems to another SSD (after partitioning = it). > Adjust the host name and the like on the copy. >=20 > (This copy later ends up having new installworld materials overlaid.) >=20 >=20 > E) In a projects/clang380-import -r294201 amd64 environment, = buildworld for > TARGET_ARCH=3Dpowerpc . WITH_LIBCPLUSPLUS=3D and clang related = material built, > gcc 4.2.1 related material not built. WITH_BOOT=3D as well. I choose > WITHOUT_DEBUG=3D and WITHOUT_DEBUG_FILES=3D . (I've not tried enabling = them yet.) > binutils is not from ports. >=20 >=20 > F) Use DESTDIR=3D with installworld to an initially empty directory = tree. tar the tree. >=20 >=20 > G) Transfer the tar file to the PowerMac. Mount the to-be-updated SSD = to > /mnt and /mnt/var. After chflags -R noschg on /mnt and /mnt/var use > tar xpf to replace things from the buildworld on /mnt and /mnt/var. >=20 > (This does leave older gcc 4.2.1 related materials in place.) >=20 > H) Dismounts, shutdown, and then boot from the updated SSD. >=20 >=20 >=20 > Note: I've never manage to get powerpc64-xtoolchain-gcc/powerpc64-gcc = to produce working 32-bit code. So I've never gotten this far via that = path. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Jan 31 03:15:18 2016 Return-Path: Delivered-To: freebsd-ppc@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 51474A73BE7 for ; Sun, 31 Jan 2016 03:15:18 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 040AEA7B for ; Sun, 31 Jan 2016 03:15:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27256 invoked from network); 31 Jan 2016 03:15:28 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 03:15:28 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 30 Jan 2016 22:15:21 -0500 (EST) Received: (qmail 20604 invoked from network); 31 Jan 2016 03:15:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 03:15:20 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 814341C43DA; Sat, 30 Jan 2016 19:15:09 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 based powerpc (32 bit) buildworld runs on a PowerMac! [problems found] From: Mark Millard In-Reply-To: Date: Sat, 30 Jan 2016 19:15:14 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Message-Id: <5AD9FDBA-BAFF-43F6-A50C-8F2CC0CEB7EF@dsl-only.net> References: <55814789-0489-48B5-867C-F678AE4EA5FF@dsl-only.net> <20160130112913.GA7950@vlakno.cz> <2CA42792-245D-48F3-9FC7-285C52D14A6A@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 03:15:18 -0000 Hmm. Too much time at this I guess. . . Reviewing again I do not find any paths that are without PRINT (i.e., = io_print) use. That should mean that io.uio.uio_iov->iov_base was = initialized but somehow changed. I still have not replicated the problem with smaller/simpler code, only = with libc/stdio use. I will back off Bug 206770 before taking a break. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 5:59 PM, Mark Millard wrote: I have submitted a minor variation of this analysis text for the = uninitialized pointer use in in libc/stdio "string output" routine = implementations as Bug 206770. If anyone finds that I missed the initialization let me know and I'll = change the status of the bug. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 5:13 PM, Mark Millard wrote: So far I'm unable to reproduce the problem with simple code replacing = the library code. And I expect that I have have a smoking gun for why. Care to check the = below and see if I missed something? As far as I can tell this is a = FreeBSD libc/stdio defect, not a clang 3.8.0 one. Unfortunately the reason is spread out in the code so it takes a bit to = describe the context for the uninitialized pointer that I expect is = involved. To start the description I note the actual, low-level failure point: > #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > 124 TLOOP1(*--dst =3D *--src); In the assembler code for this is the the *--src access that gets the = segmentation violation. I do not justify that claim here but use that = fact later. So what leads up to that? Going the other way, starting from the use of = snprintf. . . snprintf(char * __restrict str, size_t n, char const * __restrict fmt, = ...) sets up its __vfprintf(FILE *fp, locale_t locale, const char *fmt0, = va_list ap) use via: > va_list ap; > FILE f =3D FAKE_FILE; . . . > va_start(ap, fmt); > f._flags =3D __SWR | __SSTR; > f._bf._base =3D f._p =3D (unsigned char *)str; > f._bf._size =3D f._w =3D n; > ret =3D __vfprintf(&f, __get_locale(), fmt, ap); so at the __vfprintf call f._p reference the buffer that __vfprintf's = str references. __vfprintf in turn does (in part): > struct io_state io; /* I/O buffering state */ . . . > io_init(&io, fp); where io is on-stack (not implicitly initialized). The io_init does: > #define NIOV 8 > struct io_state { > FILE *fp; > struct __suio uio; /* output information: summary */ > struct __siov iov[NIOV];/* ... and individual io vectors */ > }; >=20 > static inline void > io_init(struct io_state *iop, FILE *fp) > { >=20 > iop->uio.uio_iov =3D iop->iov; > iop->uio.uio_resid =3D 0; > iop->uio.uio_iovcnt =3D 0; > iop->fp =3D fp; > } where (on stack as part of __vfprintf's io): > struct __siov { > void *iov_base; > size_t iov_len; > }; > struct __suio { > struct __siov *uio_iov; > int uio_iovcnt; > int uio_resid; > }; So via __vfprintf's io.fp->_p the str buffer is accessible for = outputting to. But in none of this or other code that I've looked at for this snprintf = use case have I found code that initializes the involved = io.uio.uio_iov->iov_base (i.e., io.iov[0].iov_base) to point to anything = specific. (Nor is iov_base's matching iov_len initialized.) Here is a stab at finding all the initializations of iov_base fields: > # grep "iov_base.*=3D" /usr/src/lib/libc/stdio/* > /usr/src/lib/libc/stdio/fputs.c: iov.iov_base =3D (void *)s; > /usr/src/lib/libc/stdio/fputws.c: iov.iov_base =3D buf; > /usr/src/lib/libc/stdio/fwrite.c: iov.iov_base =3D (void *)buf; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D (char = *)s; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D ": "; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D msgbuf; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D "\n"; > /usr/src/lib/libc/stdio/printfcommon.h: = iop->iov[iop->uio.uio_iovcnt].iov_base =3D (char *)ptr; > /usr/src/lib/libc/stdio/puts.c: iov[0].iov_base =3D (void *)s; > /usr/src/lib/libc/stdio/puts.c: iov[1].iov_base =3D "\n"; > /usr/src/lib/libc/stdio/putw.c: iov.iov_base =3D &w; > /usr/src/lib/libc/stdio/vfwprintf.c: iov.iov_base =3D buf; > /usr/src/lib/libc/stdio/xprintf.c: io->iovp->iov_base =3D = __DECONST(void *, ptr); The only file above involved in common for this context turns out to be: = /usr/src/lib/libc/stdio/printfcommon.h and the above assignment in that = file is in io_print(struct io_state *iop, const CHAR * __restrict ptr, = int len, locale_t locale), which is not in use for this context. Here is = the assignment anyway (for reference): > static inline int > io_print(struct io_state *iop, const CHAR * __restrict ptr, int len, = locale_t locale) > { >=20 > iop->iov[iop->uio.uio_iovcnt].iov_base =3D (char *)ptr; > iop->iov[iop->uio.uio_iovcnt].iov_len =3D len; > iop->uio.uio_resid +=3D len; . . . In other words: The segmentation violation is for use of __vfprintf's = uninitialized io.uio.uio_iov->iov_base . Returning to tracing the actually used code for this context to support = that claim some more. . . The __vfprintf (FILE *fp, locale_t locale, const char *fmt0, va_list ap) = eventually does: if (io_flush(&io, locale)) and io_flush(struct io_state *iop, locale_t locale) does: return (__sprint(iop->fp, &iop->uio, locale)); and _sprintf(FILE *fp, struct __suio *uio, locale_t locale) does: err =3D __sfvwrite(fp, uio); and __sfvwrite(FILE *fp, struct __suio *uio) does: p =3D iov->iov_base; len =3D iov->iov_len; where iov->iov_base is another name for __vfprintf's = io.uio.uio_iov->iov_base . __sfvwrite then uses: #define COPY(n) (void)memcpy((void *)fp->_p, (void *)p, (size_t)(n)) which fails dereferencing p (i.e., __vfprintf's io.uio.uio_iov->iov_base = ).=20 In other words (again): The segmentation violation is for use of the = uninitialized iop->uio.uio_iov->iov_base. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 5:58 AM, Mark Millard wrote: On 2016-Jan-30, at 3:29 AM, Roman Divacky wrote: > Can you file a bug in llvm bugzilla? I could try for the example code. But I'd like to make the example more = self contained first, avoiding snprintf from library code and hopefully = with a much smaller, simpler implementation involved than the = very-general library code. Separately: I'm not sure any llvm folks are going to have a way to test = unless someone shows the problem outside a FreeBSD context. = powerpc-clang (32-bit) based FreeBSD buildworld's are not exactly a = normal context at this point. My files with powerpc (32-bit) tied differences from svn for = projects/clang380-import -r294962 are: Index: /media/usr/src/sys/boot/powerpc/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/boot/powerpc/Makefile (revision 294962) +++ /media/usr/src/sys/boot/powerpc/Makefile (working copy) @@ -1,5 +1,9 @@ # $FreeBSD$ -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot +SUBDIR=3D boot1.chrp +.if ${MACHINE_ARCH} =3D=3D "powerpc64" +SUBDIR+=3D kboot +.endif +SUBDIR+=3D ofw ps3 uboot .include Index: /media/usr/src/sys/conf/Makefile.powerpc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/Makefile.powerpc (revision 294962) +++ /media/usr/src/sys/conf/Makefile.powerpc (working copy) @@ -35,7 +35,11 @@ INCLUDES+=3D -I$S/contrib/libfdt +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -msoft-float -Wa,-many +.else +CFLAGS+=3D -msoft-float +.endif # Build position-independent kernel CFLAGS+=3D -fPIC Index: /media/usr/src/sys/conf/kern.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/kern.mk (revision 294962) +++ /media/usr/src/sys/conf/kern.mk (working copy) @@ -144,7 +144,11 @@ # .if ${MACHINE_CPUARCH} =3D=3D "powerpc" CFLAGS+=3D -mno-altivec +.if ${COMPILER_TYPE} =3D=3D "clang" && ${COMPILER_VERSION} < 30800 CFLAGS.clang+=3D -mllvm -disable-ppc-float-in-variadic=3Dtrue +.else +CFLAGS.clang+=3D -msoft-float +.endif CFLAGS.gcc+=3D -msoft-float INLINE_LIMIT?=3D 15000 .endif Index: /media/usr/src/sys/conf/kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/kmod.mk (revision 294962) +++ /media/usr/src/sys/conf/kmod.mk (working copy) @@ -137,8 +137,12 @@ .endif .if ${MACHINE_CPUARCH} =3D=3D powerpc +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+=3D -fno-omit-frame-pointer .endif +.endif .if ${MACHINE_CPUARCH} =3D=3D mips CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls (I can not actually buildkernel for powerpc via clang 3.8.0. Still some = of the above is for the kernel context.) src.conf content: KERNCONF=3DGENERICvtsc-NODEBUG TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc # WITH_FAST_DEPEND=3D WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D # # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITHOUT_LIB32=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D On Sat, Jan 30, 2016 at 03:00:26AM -0800, Mark Millard wrote: > I got around to trying some more use of the 3.8.0 clang based world on = powerpc (32 bit) (now -r294962 based) and ran into: >=20 > A) Segmentation faults during signal handlers in syslogd, nfsd, = mountd, and (for SIGNFO) make. >=20 > B) ls sometimes segmentation faulting >=20 > C) make -j 6 buildworld segmentation faulting in make eventually but = make buildworld works. >=20 > I have reduced (A) to a simple program that demonstrates the behavior: >=20 >> # more sig_snprintf_use_test.c=20 >> #include >> #include >>=20 >> volatile sig_atomic_t sat =3D 0; >>=20 >> void >> handler(int sig) >> { >> char uidbuf[32]; >> (void) snprintf(uidbuf, sizeof uidbuf, "%d", 10); >> sat =3D uidbuf[0]; >> } >>=20 >> int >> main(void) >> { >> if (signal(SIGINT, handler) !=3D SIG_ERR) raise(SIGINT); >> return sat; >> } >=20 >> # ./a.out >> Segmentation fault (core dumped) >> # /usr/local/bin/gdb a.out /var/crash/a.out.1510.core >> GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD] > . . . >> warning: Unexpected size of section `.reg2/100167' in core file. >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> 124 TLOOP1(*--dst =3D *--src); >> (gdb) bt >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> #1 0x419a3984 in __sfvwrite (fp=3D, uio=3D) at /usr/src/lib/libc/stdio/fvwrite.c:128 >> #2 0x41934468 in __sprint (fp=3D, uio=3D, locale=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:164 >> #3 io_flush (iop=3D, locale=3D) at = /usr/src/lib/libc/stdio/printfcommon.h:155 >> #4 __vfprintf (fp=3D, locale=3D, = fmt0=3D, ap=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:1020 >> #5 0x4199c644 in snprintf (str=3D0xffffd734 "", n=3D, = fmt=3D0x1800850 "%d") at /usr/src/lib/libc/stdio/snprintf.c:72 >> #6 0x01800708 in handler () >> Backtrace stopped: Cannot access memory at address 0xffffd760 >=20 > (The "Unexpected size . . ." is a known problem in powerpc land at = this point, not tied to clang 3.8.0 .) >=20 > The syslogd, nfsd, mountd, and SIGINFO-related make backtraces are = similar. I got the program above from simplifying the mountd failure = context. >=20 > A direct call, handler(0), does not get the segmentation fault. >=20 > I'll note that in C the handler calling snprintf or other such is a = no-no for the general case: only abort(), _Exit(), or signal() as of C99 = as I understand. But the restriction is not true of use of raise so the = small program is still valid C99 code. Of course it appears FreeBSD = allows more than C99 does in this area. >=20 > I've not yet investigated what the original signals are in syslogd, = nfsd, or mountd. They may well indicate another problem. >=20 >=20 > I've not gotten as far classifying (B) or (C) as well. >=20 > (B) is a xo_emit context each time so far (so C elipsis use again, = like (A)) but no signal handler seems to be active. It stops in = xo_format_string_direct. My attempts at simpler code have not produced = the problem so far. >=20 > (C) is such that GDB 7.10 reports "previous frame to this frame = (corrupt stack?)" or otherwise gives up. It shows Var_Value called by = Make_Update before reporting that. gdb 6.1.1 shows more after that: = JobFinish, JobReapChild, Job_CatchChildern, Job_CatchOutput, Make_Run, = main). SIGCHLD or other such use may well be involved here. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-19, at 2:35 AM, Mark Millard wrote: >=20 > I now have an SSD that contains: >=20 > 0) installkernel material from a gcc 4.2.1 based buildkernel >=20 > 1) installworld material from a clang 3.8.0 based buildworld > (clang 3.8.0, libc++, etc.) >=20 > It boots and seems to be operating fine after booting --in both a G5 = and a G4 PowerMac. >=20 > Apparently the clang code generation has been updated to not require = an explicit -mlongcall. I had to remove those since clang rejects them = on command lines. It linked without complaint (and later seems to be = running fine). (I've seen llvm review notes mentioning the "medium = model" or some phrase like that for powerpc.) >=20 > (I've not been able to buildkernel yet for powerpc (non-64) from my = amd64 environment: rejected command lines for other issues. Thus the = current limitation to buildworld.) >=20 >=20 >=20 > To get to (1) I did the following sort of sequence: > (The first few steps deal with other issues in order to have = sufficient context.) >=20 >=20 > A) Started by installing the latest powerpc (non-64) snapshot. > ( = http://ftp1.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0= -CURRENT-powerpc-20160113-r293801-disc1.iso ) >=20 > (I had to use a PowerMac with video hardware that vt would handle.) > (Basic display, no X-windows involvement here.) >=20 >=20 > B) Rebuild, including using my usual kernel configuration that has > both vt and sc. I did this based on projects/clang380-import > -r294201 /usr/src but still using gcc 4.2.1 (native on the > PowerMac). The configuration turns off kernel debugging extras too. >=20 >=20 > C) installkernel, installworld, etc., set to use sc instead of vt, and = rebooted. >=20 > (As of this I could use the SSD in more PowerMacs by using sc instead = of vt via a /boot/loader.conf assignment.) >=20 >=20 > D) dump/restore the file systems to another SSD (after partitioning = it). > Adjust the host name and the like on the copy. >=20 > (This copy later ends up having new installworld materials overlaid.) >=20 >=20 > E) In a projects/clang380-import -r294201 amd64 environment, = buildworld for > TARGET_ARCH=3Dpowerpc . WITH_LIBCPLUSPLUS=3D and clang related = material built, > gcc 4.2.1 related material not built. WITH_BOOT=3D as well. I choose > WITHOUT_DEBUG=3D and WITHOUT_DEBUG_FILES=3D . (I've not tried enabling = them yet.) > binutils is not from ports. >=20 >=20 > F) Use DESTDIR=3D with installworld to an initially empty directory = tree. tar the tree. >=20 >=20 > G) Transfer the tar file to the PowerMac. Mount the to-be-updated SSD = to > /mnt and /mnt/var. After chflags -R noschg on /mnt and /mnt/var use > tar xpf to replace things from the buildworld on /mnt and /mnt/var. >=20 > (This does leave older gcc 4.2.1 related materials in place.) >=20 > H) Dismounts, shutdown, and then boot from the updated SSD. >=20 >=20 >=20 > Note: I've never manage to get powerpc64-xtoolchain-gcc/powerpc64-gcc = to produce working 32-bit code. So I've never gotten this far via that = path. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Jan 31 13:16:35 2016 Return-Path: Delivered-To: freebsd-ppc@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 EFC58A7407C for ; Sun, 31 Jan 2016 13:16:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4AC714D6 for ; Sun, 31 Jan 2016 13:16:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14145 invoked from network); 31 Jan 2016 13:16:27 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 13:16:27 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 31 Jan 2016 08:16:22 -0500 (EST) Received: (qmail 26981 invoked from network); 31 Jan 2016 13:16:21 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 13:16:21 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 62D71B1E002; Sun, 31 Jan 2016 05:16:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 based powerpc (32 bit) buildworld runs on a PowerMac! [stack alignment related problem for signals] From: Mark Millard In-Reply-To: <5AD9FDBA-BAFF-43F6-A50C-8F2CC0CEB7EF@dsl-only.net> Date: Sun, 31 Jan 2016 05:16:25 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <55814789-0489-48B5-867C-F678AE4EA5FF@dsl-only.net> <20160130112913.GA7950@vlakno.cz> <2CA42792-245D-48F3-9FC7-285C52D14A6A@dsl-only.net> <5AD9FDBA-BAFF-43F6-A50C-8F2CC0CEB7EF@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 13:16:35 -0000 [Next to figure out after noting the below: In FreeBSD what controls the = stack alignment produced by a signal for its handler routine? I've not = gotten that far yet. My guess is that stack alignments larger than 4 are = supposed to be in use for powerpc (32-bit) and that signal generation = should be causing the correct alignment for the handler.] I've discovered that the stack alignment varies between direct calls to = the routine that is also used to handle the signal vs. when the routine = is used via a signal. Below shows first a non-signal call then a signal = call. > (gdb) run > Starting program: /root/c_tests/a.out=20 >=20 > Breakpoint 10, 0x018006d4 in handler () > (gdb) bt > #0 0x018006d4 in handler () > #1 0x01800760 in main () > (gdb) info frame > Stack level 0, frame at 0xffffdcb0: > pc =3D 0x18006d4 in handler; saved pc =3D 0x1800760 > called by frame at 0xffffdcd0 > Arglist at 0xffffdc60, args:=20 > Locals at 0xffffdc60, Previous frame's sp is 0xffffdcb0 > Saved registers: > r31 at 0xffffdcac, pc at 0xffffdcb4, lr at 0xffffdcb4 > (gdb) cont > Continuing. >=20 > Breakpoint 10, 0x018006d4 in handler () > (gdb) bt > #0 0x018006d4 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd73c: > pc =3D 0x18006d4 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd73c > Arglist at 0xffffd6ec, args:=20 > Locals at 0xffffd6ec, Previous frame's sp is 0xffffd73c > Saved registers: > r31 at 0xffffd738, pc at 0xffffd740, lr at 0xffffd740 In direct calls "Locals at 0xffffdc60" is a multiple of 8,16,32 but not = of 64. In signal based calls "Locals at 0xffffd6ec" is a multiple of 4 but not = of 8. (Similar points could be made about the "frame at" figures.) __vfprintf in both cases gets a similar sort of stack alignment as = handler does: > (gdb) info frame > Stack level 0, frame at 0xffffdad0: > pc =3D 0x41931590 in __vfprintf = (/usr/src/lib/libc/stdio/vfprintf.c:454); saved pc =3D 0x4199c644 > called by frame at 0xffffdc60 > source language c. > Arglist at 0xffffd880, args: fp=3D0xffffdb40, locale=3D0x419cba40 = <__xlocale_global_locale>, fmt0=3D0x180085c "%d", ap=3D0xffffdc30 > Locals at 0xffffd880, Previous frame's sp is 0xffffdad0 > Saved registers: > r14 at 0xffffda88, r15 at 0xffffda8c, r16 at 0xffffda90, r17 at = 0xffffda94, r18 at 0xffffda98, r19 at 0xffffda9c, r20 at 0xffffdaa0, r21 = at 0xffffdaa4, r22 at 0xffffdaa8, r23 at 0xffffdaac, > r24 at 0xffffdab0, r25 at 0xffffdab4, r26 at 0xffffdab8, r27 at = 0xffffdabc, r28 at 0xffffdac0, r29 at 0xffffdac4, r30 at 0xffffdac8, r31 = at 0xffffdacc, pc at 0xffffdad4, lr at 0xffffdad4 vs. > (gdb) info frame > Stack level 0, frame at 0xffffd55c: > pc =3D 0x41931590 in __vfprintf = (/usr/src/lib/libc/stdio/vfprintf.c:454); saved pc =3D 0x4199c644 > called by frame at 0xffffd6ec > source language c. > Arglist at 0xffffd30c, args: fp=3D0xffffd5cc, locale=3D0x419cba40 = <__xlocale_global_locale>, fmt0=3D0x180085c "%d", ap=3D0xffffd6bc > Locals at 0xffffd30c, Previous frame's sp is 0xffffd55c > Saved registers: > r14 at 0xffffd514, r15 at 0xffffd518, r16 at 0xffffd51c, r17 at = 0xffffd520, r18 at 0xffffd524, r19 at 0xffffd528, r20 at 0xffffd52c, r21 = at 0xffffd530, r22 at 0xffffd534, r23 at 0xffffd538, > r24 at 0xffffd53c, r25 at 0xffffd540, r26 at 0xffffd544, r27 at = 0xffffd548, r28 at 0xffffd54c, r29 at 0xffffd550, r30 at 0xffffd554, r31 = at 0xffffd558, pc at 0xffffd560, lr at 0xffffd560 In the __vfprintf code below r31 (once set) is either Locals at = 0xffffd880 or Locals at 0xffffd30c, depending on the alignment. For = reference: > #define NIOV 8 > struct io_state { > FILE *fp; > struct __suio uio; /* output information: summary */ > struct __siov iov[NIOV];/* ... and individual io vectors */ > }; I've examined the code and __vfprintf (which has lots of in-lined = material from other places) has the code: > (gdb) x/64i __vfprintf > 0x41931504 <__vfprintf>: mflr r0 > 0x41931508 <__vfprintf+4>: stw r31,-4(r1) > 0x4193150c <__vfprintf+8>: stw r30,-8(r1) > 0x41931510 <__vfprintf+12>: stw r0,4(r1) > 0x41931514 <__vfprintf+16>: stwu r1,-592(r1) > 0x41931518 <__vfprintf+20>: mr r31,r1 (r31 gets = the Locals address here) > . . . > 0x41931574 <__vfprintf+112>: mr r29,r3 (FILE* passed in) > . . . > 0x4193165c <__vfprintf+344>: stw r29,296(r31) (r31+296=3D=3D= & of fp field of io_state io) > . . . > 0x4193168c <__vfprintf+392>: li r3,4 > 0x41931690 <__vfprintf+396>: addi r23,r31,296 (r31+296=3D=3D= & of fp field of io_state io) > . . . > 0x419316b0 <__vfprintf+428>: rlwimi r23,r3,0,29,29 (& of uio = field of io_state intended) Note r31+296 is either 0xFFFFD9A8 or 0xFFFFD434 depending on the stack = alignment. The rlwimi works fine for alignment by 8 or higher powers of 2 by = masking in a 4 into the address stored in r23 (equivalent to adding the = 4 in such a context). The 0xFFFFD9A8 becomes 0xFFFFD9AC in r23 after the = rlwimi. But for alignment by 4 that is not aligned by larger powers of 2 the = rlwimi leaves r23 with the value : r31+296=3D=3D& of fp field of = io_state io instead of the uio field that it should be. For the direct call sequence, not signal, > (gdb) print (struct io_state*)&buf[32] > $79 =3D (struct io_state *) 0xffffd9a8 > (gdb) print &((struct io_state*)&buf[32])->uio > $80 =3D (struct __suio *) 0xffffd9ac > (gdb) print *(struct io_state*)&buf[32] > $82 =3D {fp =3D 0xffffdb40, uio =3D {uio_iov =3D 0xffffd9b8, = uio_iovcnt =3D 1, uio_resid =3D 1}, iov =3D {{iov_base =3D 0xffffd9a7, = iov_len =3D 1}, {iov_base =3D 0x18109c8 , iov_len =3D = 1100596480}, { > iov_base =3D 0x4183f1c8, iov_len =3D 4294957520}, {iov_base =3D = 0xffffd9e0, iov_len =3D 1098984872}, {iov_base =3D 0x4183f1c8, iov_len =3D= 4294957536}, {iov_base =3D 0xffffda00, iov_len =3D 1099023964}, { > iov_base =3D 0x41832200, iov_len =3D 25233864}, {iov_base =3D = 0x1800310, iov_len =3D 1100596480}}} > . . . > Breakpoint 12, __sfvwrite (fp=3D0xffffdb40, uio=3D0xffffd9ac) at = /usr/src/lib/libc/stdio/fvwrite.c:61 vs. for the signal call sequence: > (gdb) print (struct io_state*)&buf[32] > $83 =3D (struct io_state *) 0xffffd434 > (gdb) print &((struct io_state*)&buf[32])->uio > $84 =3D (struct __suio *) 0xffffd438 > (gdb) print *(struct io_state*)&buf[32] > $85 =3D {fp =3D 0xffffd5cc, uio =3D {uio_iov =3D 0xffffd444, = uio_iovcnt =3D 1, uio_resid =3D 2}, iov =3D {{iov_base =3D 0xffffd432, = iov_len =3D 2}, {iov_base =3D 0xffffd450, iov_len =3D 4294956192}, { > iov_base =3D 0x4181bb50 , iov_len =3D = 1099266711}, {iov_base =3D 0x4a115f, iov_len =3D 4294956144}, {iov_base = =3D 0x41831370, iov_len =3D 4}, {iov_base =3D 0xffffd470,=20 > iov_len =3D 1099212600}, {iov_base =3D 0x0, iov_len =3D 0}, = {iov_base =3D 0x4, iov_len =3D 0}}} > . . . > Breakpoint 12, __sfvwrite (fp=3D0xffffd5cc, uio=3D0xffffd434) at = /usr/src/lib/libc/stdio/fvwrite.c:61 Note that uio in __sfvwrite does not agree with &((struct = io_state*)&buf[32])->uio for the signal case. Instead it matches (struct = io_state*)&buf[32] (and its ->fp (first field) field address). =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 7:15 PM, Mark Millard wrote: Hmm. Too much time at this I guess. . . Reviewing again I do not find any paths that are without PRINT (i.e., = io_print) use. That should mean that io.uio.uio_iov->iov_base was = initialized but somehow changed. I still have not replicated the problem with smaller/simpler code, only = with libc/stdio use. I will back off Bug 206770 before taking a break. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 5:59 PM, Mark Millard wrote: I have submitted a minor variation of this analysis text for the = uninitialized pointer use in in libc/stdio "string output" routine = implementations as Bug 206770. If anyone finds that I missed the initialization let me know and I'll = change the status of the bug. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 5:13 PM, Mark Millard wrote: So far I'm unable to reproduce the problem with simple code replacing = the library code. And I expect that I have have a smoking gun for why. Care to check the = below and see if I missed something? As far as I can tell this is a = FreeBSD libc/stdio defect, not a clang 3.8.0 one. Unfortunately the reason is spread out in the code so it takes a bit to = describe the context for the uninitialized pointer that I expect is = involved. To start the description I note the actual, low-level failure point: > #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > 124 TLOOP1(*--dst =3D *--src); In the assembler code for this is the the *--src access that gets the = segmentation violation. I do not justify that claim here but use that = fact later. So what leads up to that? Going the other way, starting from the use of = snprintf. . . snprintf(char * __restrict str, size_t n, char const * __restrict fmt, = ...) sets up its __vfprintf(FILE *fp, locale_t locale, const char *fmt0, = va_list ap) use via: > va_list ap; > FILE f =3D FAKE_FILE; . . . > va_start(ap, fmt); > f._flags =3D __SWR | __SSTR; > f._bf._base =3D f._p =3D (unsigned char *)str; > f._bf._size =3D f._w =3D n; > ret =3D __vfprintf(&f, __get_locale(), fmt, ap); so at the __vfprintf call f._p reference the buffer that __vfprintf's = str references. __vfprintf in turn does (in part): > struct io_state io; /* I/O buffering state */ . . . > io_init(&io, fp); where io is on-stack (not implicitly initialized). The io_init does: > #define NIOV 8 > struct io_state { > FILE *fp; > struct __suio uio; /* output information: summary */ > struct __siov iov[NIOV];/* ... and individual io vectors */ > }; >=20 > static inline void > io_init(struct io_state *iop, FILE *fp) > { >=20 > iop->uio.uio_iov =3D iop->iov; > iop->uio.uio_resid =3D 0; > iop->uio.uio_iovcnt =3D 0; > iop->fp =3D fp; > } where (on stack as part of __vfprintf's io): > struct __siov { > void *iov_base; > size_t iov_len; > }; > struct __suio { > struct __siov *uio_iov; > int uio_iovcnt; > int uio_resid; > }; So via __vfprintf's io.fp->_p the str buffer is accessible for = outputting to. But in none of this or other code that I've looked at for this snprintf = use case have I found code that initializes the involved = io.uio.uio_iov->iov_base (i.e., io.iov[0].iov_base) to point to anything = specific. (Nor is iov_base's matching iov_len initialized.) Here is a stab at finding all the initializations of iov_base fields: > # grep "iov_base.*=3D" /usr/src/lib/libc/stdio/* > /usr/src/lib/libc/stdio/fputs.c: iov.iov_base =3D (void *)s; > /usr/src/lib/libc/stdio/fputws.c: iov.iov_base =3D buf; > /usr/src/lib/libc/stdio/fwrite.c: iov.iov_base =3D (void *)buf; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D (char = *)s; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D ": "; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D msgbuf; > /usr/src/lib/libc/stdio/perror.c: v->iov_base =3D "\n"; > /usr/src/lib/libc/stdio/printfcommon.h: = iop->iov[iop->uio.uio_iovcnt].iov_base =3D (char *)ptr; > /usr/src/lib/libc/stdio/puts.c: iov[0].iov_base =3D (void *)s; > /usr/src/lib/libc/stdio/puts.c: iov[1].iov_base =3D "\n"; > /usr/src/lib/libc/stdio/putw.c: iov.iov_base =3D &w; > /usr/src/lib/libc/stdio/vfwprintf.c: iov.iov_base =3D buf; > /usr/src/lib/libc/stdio/xprintf.c: io->iovp->iov_base =3D = __DECONST(void *, ptr); The only file above involved in common for this context turns out to be: = /usr/src/lib/libc/stdio/printfcommon.h and the above assignment in that = file is in io_print(struct io_state *iop, const CHAR * __restrict ptr, = int len, locale_t locale), which is not in use for this context. Here is = the assignment anyway (for reference): > static inline int > io_print(struct io_state *iop, const CHAR * __restrict ptr, int len, = locale_t locale) > { >=20 > iop->iov[iop->uio.uio_iovcnt].iov_base =3D (char *)ptr; > iop->iov[iop->uio.uio_iovcnt].iov_len =3D len; > iop->uio.uio_resid +=3D len; . . . In other words: The segmentation violation is for use of __vfprintf's = uninitialized io.uio.uio_iov->iov_base . Returning to tracing the actually used code for this context to support = that claim some more. . . The __vfprintf (FILE *fp, locale_t locale, const char *fmt0, va_list ap) = eventually does: if (io_flush(&io, locale)) and io_flush(struct io_state *iop, locale_t locale) does: return (__sprint(iop->fp, &iop->uio, locale)); and _sprintf(FILE *fp, struct __suio *uio, locale_t locale) does: err =3D __sfvwrite(fp, uio); and __sfvwrite(FILE *fp, struct __suio *uio) does: p =3D iov->iov_base; len =3D iov->iov_len; where iov->iov_base is another name for __vfprintf's = io.uio.uio_iov->iov_base . __sfvwrite then uses: #define COPY(n) (void)memcpy((void *)fp->_p, (void *)p, (size_t)(n)) which fails dereferencing p (i.e., __vfprintf's io.uio.uio_iov->iov_base = ).=20 In other words (again): The segmentation violation is for use of the = uninitialized iop->uio.uio_iov->iov_base. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-30, at 5:58 AM, Mark Millard wrote: On 2016-Jan-30, at 3:29 AM, Roman Divacky wrote: > Can you file a bug in llvm bugzilla? I could try for the example code. But I'd like to make the example more = self contained first, avoiding snprintf from library code and hopefully = with a much smaller, simpler implementation involved than the = very-general library code. Separately: I'm not sure any llvm folks are going to have a way to test = unless someone shows the problem outside a FreeBSD context. = powerpc-clang (32-bit) based FreeBSD buildworld's are not exactly a = normal context at this point. My files with powerpc (32-bit) tied differences from svn for = projects/clang380-import -r294962 are: Index: /media/usr/src/sys/boot/powerpc/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/boot/powerpc/Makefile (revision 294962) +++ /media/usr/src/sys/boot/powerpc/Makefile (working copy) @@ -1,5 +1,9 @@ # $FreeBSD$ -SUBDIR=3D boot1.chrp kboot ofw ps3 uboot +SUBDIR=3D boot1.chrp +.if ${MACHINE_ARCH} =3D=3D "powerpc64" +SUBDIR+=3D kboot +.endif +SUBDIR+=3D ofw ps3 uboot .include Index: /media/usr/src/sys/conf/Makefile.powerpc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/Makefile.powerpc (revision 294962) +++ /media/usr/src/sys/conf/Makefile.powerpc (working copy) @@ -35,7 +35,11 @@ INCLUDES+=3D -I$S/contrib/libfdt +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -msoft-float -Wa,-many +.else +CFLAGS+=3D -msoft-float +.endif # Build position-independent kernel CFLAGS+=3D -fPIC Index: /media/usr/src/sys/conf/kern.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/kern.mk (revision 294962) +++ /media/usr/src/sys/conf/kern.mk (working copy) @@ -144,7 +144,11 @@ # .if ${MACHINE_CPUARCH} =3D=3D "powerpc" CFLAGS+=3D -mno-altivec +.if ${COMPILER_TYPE} =3D=3D "clang" && ${COMPILER_VERSION} < 30800 CFLAGS.clang+=3D -mllvm -disable-ppc-float-in-variadic=3Dtrue +.else +CFLAGS.clang+=3D -msoft-float +.endif CFLAGS.gcc+=3D -msoft-float INLINE_LIMIT?=3D 15000 .endif Index: /media/usr/src/sys/conf/kmod.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /media/usr/src/sys/conf/kmod.mk (revision 294962) +++ /media/usr/src/sys/conf/kmod.mk (working copy) @@ -137,8 +137,12 @@ .endif .if ${MACHINE_CPUARCH} =3D=3D powerpc +.if ${COMPILER_TYPE} =3D=3D "gcc" CFLAGS+=3D -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+=3D -fno-omit-frame-pointer .endif +.endif .if ${MACHINE_CPUARCH} =3D=3D mips CFLAGS+=3D -G0 -fno-pic -mno-abicalls -mlong-calls (I can not actually buildkernel for powerpc via clang 3.8.0. Still some = of the above is for the kernel context.) src.conf content: KERNCONF=3DGENERICvtsc-NODEBUG TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc # WITH_FAST_DEPEND=3D WITH_LIBCPLUSPLUS=3D WITH_BOOT=3D WITH_BINUTILS_BOOTSTRAP=3D WITH_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D # # lldb requires missing atomic 8-byte operations for powerpc (non-64) WITHOUT_LLDB=3D # WITHOUT_LIB32=3D WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D MALLOC_PRODUCTION=3D # WITH_DEBUG_FILES=3D On Sat, Jan 30, 2016 at 03:00:26AM -0800, Mark Millard wrote: > I got around to trying some more use of the 3.8.0 clang based world on = powerpc (32 bit) (now -r294962 based) and ran into: >=20 > A) Segmentation faults during signal handlers in syslogd, nfsd, = mountd, and (for SIGNFO) make. >=20 > B) ls sometimes segmentation faulting >=20 > C) make -j 6 buildworld segmentation faulting in make eventually but = make buildworld works. >=20 > I have reduced (A) to a simple program that demonstrates the behavior: >=20 >> # more sig_snprintf_use_test.c=20 >> #include >> #include >>=20 >> volatile sig_atomic_t sat =3D 0; >>=20 >> void >> handler(int sig) >> { >> char uidbuf[32]; >> (void) snprintf(uidbuf, sizeof uidbuf, "%d", 10); >> sat =3D uidbuf[0]; >> } >>=20 >> int >> main(void) >> { >> if (signal(SIGINT, handler) !=3D SIG_ERR) raise(SIGINT); >> return sat; >> } >=20 >> # ./a.out >> Segmentation fault (core dumped) >> # /usr/local/bin/gdb a.out /var/crash/a.out.1510.core >> GNU gdb (GDB) 7.10 [GDB v7.10 for FreeBSD] > . . . >> warning: Unexpected size of section `.reg2/100167' in core file. >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> 124 TLOOP1(*--dst =3D *--src); >> (gdb) bt >> #0 0x419a89c8 in memcpy (dst0=3D0xffffd734, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 >> #1 0x419a3984 in __sfvwrite (fp=3D, uio=3D) at /usr/src/lib/libc/stdio/fvwrite.c:128 >> #2 0x41934468 in __sprint (fp=3D, uio=3D, locale=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:164 >> #3 io_flush (iop=3D, locale=3D) at = /usr/src/lib/libc/stdio/printfcommon.h:155 >> #4 __vfprintf (fp=3D, locale=3D, = fmt0=3D, ap=3D) at = /usr/src/lib/libc/stdio/vfprintf.c:1020 >> #5 0x4199c644 in snprintf (str=3D0xffffd734 "", n=3D, = fmt=3D0x1800850 "%d") at /usr/src/lib/libc/stdio/snprintf.c:72 >> #6 0x01800708 in handler () >> Backtrace stopped: Cannot access memory at address 0xffffd760 >=20 > (The "Unexpected size . . ." is a known problem in powerpc land at = this point, not tied to clang 3.8.0 .) >=20 > The syslogd, nfsd, mountd, and SIGINFO-related make backtraces are = similar. I got the program above from simplifying the mountd failure = context. >=20 > A direct call, handler(0), does not get the segmentation fault. >=20 > I'll note that in C the handler calling snprintf or other such is a = no-no for the general case: only abort(), _Exit(), or signal() as of C99 = as I understand. But the restriction is not true of use of raise so the = small program is still valid C99 code. Of course it appears FreeBSD = allows more than C99 does in this area. >=20 > I've not yet investigated what the original signals are in syslogd, = nfsd, or mountd. They may well indicate another problem. >=20 >=20 > I've not gotten as far classifying (B) or (C) as well. >=20 > (B) is a xo_emit context each time so far (so C elipsis use again, = like (A)) but no signal handler seems to be active. It stops in = xo_format_string_direct. My attempts at simpler code have not produced = the problem so far. >=20 > (C) is such that GDB 7.10 reports "previous frame to this frame = (corrupt stack?)" or otherwise gives up. It shows Var_Value called by = Make_Update before reporting that. gdb 6.1.1 shows more after that: = JobFinish, JobReapChild, Job_CatchChildern, Job_CatchOutput, Make_Run, = main). SIGCHLD or other such use may well be involved here. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-19, at 2:35 AM, Mark Millard wrote: >=20 > I now have an SSD that contains: >=20 > 0) installkernel material from a gcc 4.2.1 based buildkernel >=20 > 1) installworld material from a clang 3.8.0 based buildworld > (clang 3.8.0, libc++, etc.) >=20 > It boots and seems to be operating fine after booting --in both a G5 = and a G4 PowerMac. >=20 > Apparently the clang code generation has been updated to not require = an explicit -mlongcall. I had to remove those since clang rejects them = on command lines. It linked without complaint (and later seems to be = running fine). (I've seen llvm review notes mentioning the "medium = model" or some phrase like that for powerpc.) >=20 > (I've not been able to buildkernel yet for powerpc (non-64) from my = amd64 environment: rejected command lines for other issues. Thus the = current limitation to buildworld.) >=20 >=20 >=20 > To get to (1) I did the following sort of sequence: > (The first few steps deal with other issues in order to have = sufficient context.) >=20 >=20 > A) Started by installing the latest powerpc (non-64) snapshot. > ( = http://ftp1.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0= -CURRENT-powerpc-20160113-r293801-disc1.iso ) >=20 > (I had to use a PowerMac with video hardware that vt would handle.) > (Basic display, no X-windows involvement here.) >=20 >=20 > B) Rebuild, including using my usual kernel configuration that has > both vt and sc. I did this based on projects/clang380-import > -r294201 /usr/src but still using gcc 4.2.1 (native on the > PowerMac). The configuration turns off kernel debugging extras too. >=20 >=20 > C) installkernel, installworld, etc., set to use sc instead of vt, and = rebooted. >=20 > (As of this I could use the SSD in more PowerMacs by using sc instead = of vt via a /boot/loader.conf assignment.) >=20 >=20 > D) dump/restore the file systems to another SSD (after partitioning = it). > Adjust the host name and the like on the copy. >=20 > (This copy later ends up having new installworld materials overlaid.) >=20 >=20 > E) In a projects/clang380-import -r294201 amd64 environment, = buildworld for > TARGET_ARCH=3Dpowerpc . WITH_LIBCPLUSPLUS=3D and clang related = material built, > gcc 4.2.1 related material not built. WITH_BOOT=3D as well. I choose > WITHOUT_DEBUG=3D and WITHOUT_DEBUG_FILES=3D . (I've not tried enabling = them yet.) > binutils is not from ports. >=20 >=20 > F) Use DESTDIR=3D with installworld to an initially empty directory = tree. tar the tree. >=20 >=20 > G) Transfer the tar file to the PowerMac. Mount the to-be-updated SSD = to > /mnt and /mnt/var. After chflags -R noschg on /mnt and /mnt/var use > tar xpf to replace things from the buildworld on /mnt and /mnt/var. >=20 > (This does leave older gcc 4.2.1 related materials in place.) >=20 > H) Dismounts, shutdown, and then boot from the updated SSD. >=20 >=20 >=20 > Note: I've never manage to get powerpc64-xtoolchain-gcc/powerpc64-gcc = to produce working 32-bit code. So I've never gotten this far via that = path. >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Jan 31 13:55:23 2016 Return-Path: Delivered-To: freebsd-ppc@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 B3F59A732C2 for ; Sun, 31 Jan 2016 13:55:23 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50E28F35 for ; Sun, 31 Jan 2016 13:55:22 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18677 invoked from network); 31 Jan 2016 13:55:33 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 13:55:33 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 31 Jan 2016 08:55:27 -0500 (EST) Received: (qmail 10903 invoked from network); 31 Jan 2016 13:55:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 31 Jan 2016 13:55:26 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 288161C43D5; Sun, 31 Jan 2016 05:55:19 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers Date: Sun, 31 Jan 2016 05:55:20 -0800 Message-Id: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> Cc: FreeBSD PowerPC ML , FreeBSD Toolchain To: Nathan Whitehorn , Justin Hibbits Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 13:55:23 -0000 3 quick FreeBSD for powerpc (32-bit) questions: A) For PowerPC (32-bit) what is the stack alignment requirement by the = ABI(s) that FreeBSD targets? B) Are signal handlers supposed to be given that alignment? I ask because signal handlers are at times begin given just 4-byte = alignment but clang 3.8.0 powerpc's code generation can depend on the = alignment being more than 4. clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 = relative to what would need to be an aligned address with alignment 8 or = more instead of adding 0x4 to a more arbitrary address. So far I've only seen less than 8 byte stack alignment via signal = handler activity. C) Which should be blamed for problems here: clang's code generation, = FreeBSD's stack alignment handling for signals, or both? =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Jan 31 14:10:31 2016 Return-Path: Delivered-To: freebsd-ppc@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 38908A73DE8; Sun, 31 Jan 2016 14:10:31 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 029F31AAC; Sun, 31 Jan 2016 14:10:30 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id E84331E207B7; Sun, 31 Jan 2016 15:08:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1454249287; bh=SWIR1MdPAqCmM/oXpYaw2DvdH9SyBCH8ut/N2i3vWmE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=HfYWyUxkUCve4qPlMrmRyg+25XUtJWDZGSR1PPhbRuCxs5DmThmrXksw09FRQSvK7 9MhUaXeCeWegdATiFNpwF0XzMFuRfF1fzjT+0WZRElZ9yOS/ED3gwcm538Rw7TdStz fCbCQMruTIoa7zF1zaH7io+ohCHP/kLMMRmxl9HU= Date: Sun, 31 Jan 2016 15:08:07 +0100 From: Roman Divacky To: Mark Millard Cc: Nathan Whitehorn , Justin Hibbits , FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers Message-ID: <20160131140807.GA83147@vlakno.cz> References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2016 14:10:31 -0000 Fwiw, LLVM expect 16B aligned stack on PowerPC. On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: > 3 quick FreeBSD for powerpc (32-bit) questions: > > > A) For PowerPC (32-bit) what is the stack alignment requirement by the ABI(s) that FreeBSD targets? > > B) Are signal handlers supposed to be given that alignment? > > > I ask because signal handlers are at times begin given just 4-byte alignment but clang 3.8.0 powerpc's code generation can depend on the alignment being more than 4. > > clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 relative to what would need to be an aligned address with alignment 8 or more instead of adding 0x4 to a more arbitrary address. > > So far I've only seen less than 8 byte stack alignment via signal handler activity. > > > C) Which should be blamed for problems here: clang's code generation, FreeBSD's stack alignment handling for signals, or both? > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Mon Feb 1 00:41:14 2016 Return-Path: Delivered-To: freebsd-ppc@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 A2616A74C6D for ; Mon, 1 Feb 2016 00:41:14 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 584E6938 for ; Mon, 1 Feb 2016 00:41:13 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27054 invoked from network); 1 Feb 2016 00:41:11 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 00:41:11 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 31 Jan 2016 19:41:07 -0500 (EST) Received: (qmail 24110 invoked from network); 1 Feb 2016 00:41:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 00:41:07 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E9A6C1C42A3; Sun, 31 Jan 2016 16:41:06 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers From: Mark Millard In-Reply-To: <20160131140807.GA83147@vlakno.cz> Date: Sun, 31 Jan 2016 16:41:11 -0800 Cc: Nathan Whitehorn , Justin Hibbits , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 00:41:14 -0000 I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import stack = alignment problem for TARGET_ARCH=3Dpowerpc signal delivery. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 6:08 AM, Roman Divacky wrote: Fwiw, LLVM expect 16B aligned stack on PowerPC. On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: > 3 quick FreeBSD for powerpc (32-bit) questions: >=20 >=20 > A) For PowerPC (32-bit) what is the stack alignment requirement by the = ABI(s) that FreeBSD targets? >=20 > B) Are signal handlers supposed to be given that alignment? >=20 >=20 > I ask because signal handlers are at times begin given just 4-byte = alignment but clang 3.8.0 powerpc's code generation can depend on the = alignment being more than 4. >=20 > clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 = relative to what would need to be an aligned address with alignment 8 or = more instead of adding 0x4 to a more arbitrary address. >=20 > So far I've only seen less than 8 byte stack alignment via signal = handler activity. >=20 >=20 > C) Which should be blamed for problems here: clang's code generation, = FreeBSD's stack alignment handling for signals, or both? >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Mon Feb 1 00:42:27 2016 Return-Path: Delivered-To: freebsd-ppc@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 4332FA74DAF; Mon, 1 Feb 2016 00:42:27 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1985AADB; Mon, 1 Feb 2016 00:42:27 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-oi0-x232.google.com with SMTP id p187so79748145oia.2; Sun, 31 Jan 2016 16:42:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=As1DNuZwlFGm66RwQLoKvCyvk+Fpx4BcQGjg1b5HLHw=; b=DCqGhs2FK27x85vyZSvDyHnvcFi9BDyXoDBo2d9CUNljuIRjrDBN9Zku2wrJFjTJSI /ueLNsDhXwPxg5Nod8phjdG6nu5ZhyhZJulbDdUHEh+DOsHno9UQI5SolIhvOdjrCbYK wl4YOSYLBysMEBF3GKJ+5S6grRnmcR2uBWPeuL4Ps8Dc8ww7X6Z1dz4lfeMib6HRqA5g VNmJdhoX8btKsByQJXqHWsVzYVir0jxCboxqBJFT1qE6RllMQXtYtFZG2Z8qyb+p7nUk ZD1Gl8Yqqg8ZYVS8idkRO55y5+FjbTbGoffp+TdbJUR53fxOvaNAg6+ukDs8bR7TdYIA sg8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=As1DNuZwlFGm66RwQLoKvCyvk+Fpx4BcQGjg1b5HLHw=; b=V20M/mKe0rcSSpO1GJ3iEOqhQPdw0PnjVMK+yLy4nEMnNJ0QvJ9IoT7VgOU9sBFG52 oHqH+Dnfj4vN9cfp4Yq0kFtW0AhV9/0J47kfc8pVWgtH7K//hzrPHx4Dvfnj2dCmx++m DZymVY7w0zAiSyGdNwNq4jgSRqbZ/w2uFTiAajRNg/7jorzy9ryn1A3V10EcVf38k/Ch yqDgN+ErpDw5+D4SOKGrzhFPQfm2uBysZQfchT1nyvdlX0rlq0ROZCQ9+1ZIqqtmz8eJ Ln/+Doicu1kVBpys7LOjF/nyh5wnKP82nJ0Q5Rgl4WWEjfP8UZenL90jJH5K8+Ga0Rcv 8ACg== X-Gm-Message-State: AG10YOR8xjRS4mYRajf6C+VBA/NOp+n/EOVBe9N5m+XHRkjXfWhGsKiBWrCu6LZprPse3VREzTs3bOLZnDedLw== MIME-Version: 1.0 X-Received: by 10.202.85.139 with SMTP id j133mr9476280oib.4.1454287345651; Sun, 31 Jan 2016 16:42:25 -0800 (PST) Received: by 10.182.74.101 with HTTP; Sun, 31 Jan 2016 16:42:25 -0800 (PST) Received: by 10.182.74.101 with HTTP; Sun, 31 Jan 2016 16:42:25 -0800 (PST) In-Reply-To: <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> Date: Sun, 31 Jan 2016 18:42:25 -0600 Message-ID: Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers From: Justin Hibbits To: Mark Millard Cc: freebsd-toolchain@freebsd.org, Nathan Whitehorn , Roman Divacky , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 00:42:27 -0000 I'll take a look at the signal code in the kernel this evening. -Justin On Jan 31, 2016 18:41, "Mark Millard" wrote: > I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import stack > alignment problem for TARGET_ARCH=powerpc signal delivery. > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Jan-31, at 6:08 AM, Roman Divacky wrote: > > Fwiw, LLVM expect 16B aligned stack on PowerPC. > > On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: > > 3 quick FreeBSD for powerpc (32-bit) questions: > > > > > > A) For PowerPC (32-bit) what is the stack alignment requirement by the > ABI(s) that FreeBSD targets? > > > > B) Are signal handlers supposed to be given that alignment? > > > > > > I ask because signal handlers are at times begin given just 4-byte > alignment but clang 3.8.0 powerpc's code generation can depend on the > alignment being more than 4. > > > > clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 > relative to what would need to be an aligned address with alignment 8 or > more instead of adding 0x4 to a more arbitrary address. > > > > So far I've only seen less than 8 byte stack alignment via signal > handler activity. > > > > > > C) Which should be blamed for problems here: clang's code generation, > FreeBSD's stack alignment handling for signals, or both? > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > _______________________________________________ > > freebsd-toolchain@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > > To unsubscribe, send any mail to " > freebsd-toolchain-unsubscribe@freebsd.org" > > From owner-freebsd-ppc@freebsd.org Mon Feb 1 01:51:01 2016 Return-Path: Delivered-To: freebsd-ppc@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 3245EA748BD; Mon, 1 Feb 2016 01:51:01 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0718ACC; Mon, 1 Feb 2016 01:51:00 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-io0-x230.google.com with SMTP id 9so62750391iom.1; Sun, 31 Jan 2016 17:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references; bh=hIfHbD/67r9Kv3okBN6a0oaP/0pNU/B2nxsLM5jmgZk=; b=rkZz5OhZvkTqZG3n1OcPBIbrHzoGmBnwSPXDPcU/N4epQ1nI/h8CAt/F+9tO4nUvZz JeBqchEb6mi9GhipyfVYWpy55S9gEzyUOkmvv4QaslVYdCUArtKsebP69S91K9/wppoz ozcguHE4Ny3tYzn3y3QeWbWrV/aCyZjQ0klQdTC/8VJAuTC4holrjYbiAEi7ipgK5A1F gjOJ6bT+hyI8PaFG7+uMX2D97Jz0f7kHOzCmWpd+d/PSNx72yUUZDLI5a/5DmUYxWpx8 JVoVl2vuvcGeptOECNDquXsP5CjCghh+f4N3nFf0KpZvUSS26wmKvnkOSR+zl6fWvnNb d6MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references; bh=hIfHbD/67r9Kv3okBN6a0oaP/0pNU/B2nxsLM5jmgZk=; b=gQe0o22+8Fy8brNr8mlz51ZB88Oaz8f451ozxrpq2/qJn4/Uhdo2VQci1B32SXNl09 wW6/YWBH7xYNKofHv6E7IsHGDB/5ts9kXbTeYZLSrIWzs9MjS4goy4pXY3dTDHGVgW8v SalNnWMCnt7WhY0+m8FIbd1O/WlBmB7cptNfLKzxfmH+sXfwqPq9B/l0jKA29PDIMqhL zx2p4Z0Sm3goLLVw0GHmfTrY67fU/55ZFiNM0lGn6CRyW/Az6e0pSx+FSAYv7h7ofnsJ XvsQtHR5QHBEv5dIOx3z6KDNYogkUPJL+ooDH2El9sha1QoA0PtqZoGrDzH3fqO/9PSN KQ3w== X-Gm-Message-State: AG10YORts7jG+Rk7o0PTl6lnI3m6dnBDDtb56me+rVPfOQTMTx80i22IAz67VWrJxM3lpQ== X-Received: by 10.107.15.223 with SMTP id 92mr17449797iop.3.1454291460340; Sun, 31 Jan 2016 17:51:00 -0800 (PST) Received: from blackstar.knownspace (c-98-240-160-157.hsd1.mn.comcast.net. [98.240.160.157]) by smtp.gmail.com with ESMTPSA id ii1sm3549432igb.11.2016.01.31.17.50.59 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 31 Jan 2016 17:50:59 -0800 (PST) Cc: Roman Divacky , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Message-Id: From: Justin Hibbits To: Mark Millard In-Reply-To: <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers Date: Sun, 31 Jan 2016 19:50:58 -0600 References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> X-Mailer: Apple Mail (2.936) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 01:51:01 -0000 Does this occur with gcc-built world and/or kernel? You could put some printf()s in sendsig(), and there are KTR tracepoints already present. The code assumes a fully aligned user stack, which should be correct, but may not be. - Justin On Jan 31, 2016, at 6:41 PM, Mark Millard wrote: > I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import > stack alignment problem for TARGET_ARCH=powerpc signal delivery. > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Jan-31, at 6:08 AM, Roman Divacky > wrote: > > Fwiw, LLVM expect 16B aligned stack on PowerPC. > > On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: >> 3 quick FreeBSD for powerpc (32-bit) questions: >> >> >> A) For PowerPC (32-bit) what is the stack alignment requirement by >> the ABI(s) that FreeBSD targets? >> >> B) Are signal handlers supposed to be given that alignment? >> >> >> I ask because signal handlers are at times begin given just 4-byte >> alignment but clang 3.8.0 powerpc's code generation can depend on >> the alignment being more than 4. >> >> clang 3.8.0 can calculate addresses by, for example, masking in a >> 0x4 relative to what would need to be an aligned address with >> alignment 8 or more instead of adding 0x4 to a more arbitrary >> address. >> >> So far I've only seen less than 8 byte stack alignment via signal >> handler activity. >> >> >> C) Which should be blamed for problems here: clang's code >> generation, FreeBSD's stack alignment handling for signals, or both? >> >> === >> Mark Millard >> markmi at dsl-only.net >> >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org >> " > From owner-freebsd-ppc@freebsd.org Mon Feb 1 02:32:42 2016 Return-Path: Delivered-To: freebsd-ppc@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 19042A7571A for ; Mon, 1 Feb 2016 02:32:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D05821EEB for ; Mon, 1 Feb 2016 02:32:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 30783 invoked from network); 1 Feb 2016 02:32:38 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 02:32:38 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 31 Jan 2016 21:32:45 -0500 (EST) Received: (qmail 25252 invoked from network); 1 Feb 2016 02:32:45 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 02:32:45 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F1E891C43A8; Sun, 31 Jan 2016 18:32:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers From: Mark Millard In-Reply-To: Date: Sun, 31 Jan 2016 18:32:38 -0800 Cc: Roman Divacky , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 02:32:42 -0000 [I've never noticed gcc 4.2.1 generating code that was based on = presuming the alignment was present. For example: it always seems to use = addition to deal with address offsets, never masking. So I'd not expect = to see segmentation faults for that context even when the stack is = aligned modulo only 4. Separately checking the alignment is appropriate = for me to do.] A) The reported context: The kernel context here is a gcc 4.2.1 based buildkernel then = installkernel. The world context here is a clang 3.8.0 based buildworld then = installworld. The program context here is a clang 3.8.0 based: > # clang -std=3Dc11 -Wall -Wpedantic sig_snprintf_use_test.c > # /usr/local/bin/gdb a.out Using "break handler" in gdb (7.10_5) and using "info frame" when it = stops for the "raise" shows the misalignment of the frame that the = handler was given ny the signal delivery. By contrast the earlier direct call of the handler gets a "info frame" = result that shows the expected sort of alignment. I find no evidence of frame/stack misalignment via gdb except for the = one that is created by the signal delivery. B) I'll look at trying one or more of gcc 4.2.1, gcc49, gcc5 for the = program context, still based on a clang 3.8.0 buildworld and gcc 4.2.1 = buildkernel based on projects/clang380-import (-r294962). C) I will look at trying the same program builds on a pure gcc 4.2.1 = buildworld/buildkernel context. (Likely 11.0-CURRENT -r294960.) I'll send more results when I have them. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 5:50 PM, Justin Hibbits = wrote: Does this occur with gcc-built world and/or kernel? You could put some = printf()s in sendsig(), and there are KTR tracepoints already present. = The code assumes a fully aligned user stack, which should be correct, = but may not be. - Justin On Jan 31, 2016, at 6:41 PM, Mark Millard wrote: > I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import = stack alignment problem for TARGET_ARCH=3Dpowerpc signal delivery. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-31, at 6:08 AM, Roman Divacky = wrote: >=20 > Fwiw, LLVM expect 16B aligned stack on PowerPC. >=20 > On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: >> 3 quick FreeBSD for powerpc (32-bit) questions: >>=20 >>=20 >> A) For PowerPC (32-bit) what is the stack alignment requirement by = the ABI(s) that FreeBSD targets? >>=20 >> B) Are signal handlers supposed to be given that alignment? >>=20 >>=20 >> I ask because signal handlers are at times begin given just 4-byte = alignment but clang 3.8.0 powerpc's code generation can depend on the = alignment being more than 4. >>=20 >> clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 = relative to what would need to be an aligned address with alignment 8 or = more instead of adding 0x4 to a more arbitrary address. >>=20 >> So far I've only seen less than 8 byte stack alignment via signal = handler activity. >>=20 >>=20 >> C) Which should be blamed for problems here: clang's code generation, = FreeBSD's stack alignment handling for signals, or both? >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@freebsd.org Mon Feb 1 05:12:34 2016 Return-Path: Delivered-To: freebsd-ppc@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 7F9B7A99F75 for ; Mon, 1 Feb 2016 05:12:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7AB14F5B for ; Mon, 1 Feb 2016 05:12:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 7480 invoked from network); 1 Feb 2016 05:12:44 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 05:12:44 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 01 Feb 2016 00:12:34 -0500 (EST) Received: (qmail 24605 invoked from network); 1 Feb 2016 05:12:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 05:12:34 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F2FB81C43DC; Sun, 31 Jan 2016 21:12:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers From: Mark Millard In-Reply-To: <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> Date: Sun, 31 Jan 2016 21:12:30 -0800 Cc: Roman Divacky , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 05:12:34 -0000 A summary of the later finding details for what I've done so far: It is system library code (__vfprintf and its inline io_flush call to = __sfvwrite) that may produce and use a potentially bad &iop->uio = address, depending the mix of how the calculation works and the = stack/frame alignment present in signal delivery. The gcc 4.2.1 vs. = clang 3.8.0 program status makes no difference to if it ends up with a = segmentation fault or not. When __vfprintf and its inline io_flush call to __sfvwrite is compiled = by gcc 4.2.1 --which always uses addition for offsets, voiding alignment = assumptions-- no variant of the program gets a segmentation fault. gcc = 4.2.1 does not create the dependency on the alignment that clang 3.8.0 = does. Yet the misalignment is present. (See the details.) When clang3.8.0 compiles __vfprintf and its inline io_flush call to = __sfvwrite --which uses masking for the offset in calculating &iop->uio, = making alignment assumptions-- every variant of the program gets a = segmentation fault. (The misalignment is still present.) The details for the misalignment evidence follow. For (C) "on a pure gcc 4.2.1 buildworld/buildkernel system". . . C0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt =20 > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd73c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd73c > Arglist at 0xffffd6fc, args:=20 > Locals at 0xffffd6fc, Previous frame's sp is 0xffffd73c > Saved registers: > r31 at 0xffffd738, pc at 0xffffd740, lr at 0xffffd740 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). In this case I also list __vfprintf's misalignment evidence for = reference: (break __vfprintf used.) > (gdb) info frame > Stack level 0, frame at 0xffffd57c: > pc =3D 0x41930af8 in __vfprintf = (/usr/src/lib/libc/stdio/vfprintf.c:452); saved pc =3D 0x41992e18 > called by frame at 0xffffd6fc > source language c. > Arglist at 0xffffd29c, args: fp=3D0xffffd5dc, locale=3D0x419c41e0 = <__xlocale_global_locale>, fmt0=3D0x1800a1c "%d", ap=3D0xffffd6cc > Locals at 0xffffd29c, Previous frame's sp is 0xffffd57c > Saved registers: > r30 at 0xffffd574, r31 at 0xffffd578, pc at 0xffffd580, lr at = 0xffffd580 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). Just to have one for reference, here is the "info frame" for the direct = handler call --which gets a properly aligned frame/stack: > (gdb) info frame > Stack level 0, frame at 0xffffdcc0: > pc =3D 0x18006e0 in handler; saved pc =3D 0x1800734 > called by frame at 0xffffdcd0 > Arglist at 0xffffdc80, args:=20 > Locals at 0xffffdc80, Previous frame's sp is 0xffffdcc0 > Saved registers: > r31 at 0xffffdcbc, pc at 0xffffdcc4, lr at 0xffffdcc4 Only the signal delivery is creating non-aligned stack frames. C1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > (gdb) info frame > Stack level 0, frame at 0xffffd70c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd70c > Arglist at 0xffffd6cc, args:=20 > Locals at 0xffffd6cc, Previous frame's sp is 0xffffd70c > Saved registers: > r31 at 0xffffd708, pc at 0xffffd710, lr at 0xffffd710 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). For (B) "on a clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix". . . B0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (B) context: This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd74c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd74c > Arglist at 0xffffd70c, args:=20 > Locals at 0xffffd70c, Previous frame's sp is 0xffffd74c > Saved registers: > r31 at 0xffffd748, pc at 0xffffd750, lr at 0xffffd750 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd714, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); B1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (B) context: (i.e., what I originally reported on and submitted a Bug report for) This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006d0 in handler () > (gdb) info frame > Stack level 0, frame at 0xffffd71c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd71c > Arglist at 0xffffd6dc, args:=20 > Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > Saved registers: > r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd6f4, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). More context notes. . . The "pure gcc 4.2.1 buildworld/buildkernel system" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r294960M: Wed Jan = 27 18:25:04 PST 2016 = root@FBSDG4C0:/usr/obj/gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODE= BUG powerpc 1100097 1100097 The "clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r294962M: Fri Jan = 29 18:28:17 PST 2016 = markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.powerpc/usr/src/sys/GENERI= Cvtsc-NODEBUG powerpc 1100097 1100097 (Same PowerMac, different SSD.) [I have renamed a.out's to indicate compiler context as I've gone = along.] [I copied each a.out to the other SSD for use after compiling/linking.] [I'm not generally showing the "direct call" properly aligned "info = frame" texts.] [handle SIGINFO nostop print pass; break handler used in gdb 7.10_5.] [For gcc 4.2.1 I used: gcc -std=3Dc99 -Wall sig_snprintf_use_test.c .] [For clang 3.8.0 I used: clang -std=3Dc11 -Wall -Wpedantic = sig_snprintf_use_test.c .] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 6:32 PM, Mark Millard wrote: > [I've never noticed gcc 4.2.1 generating code that was based on = presuming the alignment was present. For example: it always seems to use = addition to deal with address offsets, never masking. So I'd not expect = to see segmentation faults for that context even when the stack is = aligned modulo only 4. Separately checking the alignment is appropriate = for me to do.] >=20 > A) The reported context: >=20 > The kernel context here is a gcc 4.2.1 based buildkernel then = installkernel. > The world context here is a clang 3.8.0 based buildworld then = installworld. > The program context here is a clang 3.8.0 based: >=20 >> # clang -std=3Dc11 -Wall -Wpedantic sig_snprintf_use_test.c >> # /usr/local/bin/gdb a.out >=20 >=20 > Using "break handler" in gdb (7.10_5) and using "info frame" when it = stops for the "raise" shows the misalignment of the frame that the = handler was given ny the signal delivery. >=20 > By contrast the earlier direct call of the handler gets a "info frame" = result that shows the expected sort of alignment. >=20 > I find no evidence of frame/stack misalignment via gdb except for the = one that is created by the signal delivery. >=20 >=20 > B) I'll look at trying one or more of gcc 4.2.1, gcc49, gcc5 for the = program context, still based on a clang 3.8.0 buildworld and gcc 4.2.1 = buildkernel based on projects/clang380-import (-r294962). >=20 > C) I will look at trying the same program builds on a pure gcc 4.2.1 = buildworld/buildkernel context. (Likely 11.0-CURRENT -r294960.) >=20 >=20 > I'll send more results when I have them. >=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 5:50 PM, Justin Hibbits = wrote: Does this occur with gcc-built world and/or kernel? You could put some = printf()s in sendsig(), and there are KTR tracepoints already present. = The code assumes a fully aligned user stack, which should be correct, = but may not be. - Justin On Jan 31, 2016, at 6:41 PM, Mark Millard wrote: > I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import = stack alignment problem for TARGET_ARCH=3Dpowerpc signal delivery. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-31, at 6:08 AM, Roman Divacky = wrote: >=20 > Fwiw, LLVM expect 16B aligned stack on PowerPC. >=20 > On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: >> 3 quick FreeBSD for powerpc (32-bit) questions: >>=20 >>=20 >> A) For PowerPC (32-bit) what is the stack alignment requirement by = the ABI(s) that FreeBSD targets? >>=20 >> B) Are signal handlers supposed to be given that alignment? >>=20 >>=20 >> I ask because signal handlers are at times begin given just 4-byte = alignment but clang 3.8.0 powerpc's code generation can depend on the = alignment being more than 4. >>=20 >> clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 = relative to what would need to be an aligned address with alignment 8 or = more instead of adding 0x4 to a more arbitrary address. >>=20 >> So far I've only seen less than 8 byte stack alignment via signal = handler activity. >>=20 >>=20 >> C) Which should be blamed for problems here: clang's code generation, = FreeBSD's stack alignment handling for signals, or both? >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@freebsd.org Mon Feb 1 06:47:11 2016 Return-Path: Delivered-To: freebsd-ppc@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 E962CA7593A for ; Mon, 1 Feb 2016 06:47:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD44CB8C for ; Mon, 1 Feb 2016 06:47:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 28549 invoked from network); 1 Feb 2016 06:47:09 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 06:47:09 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 01 Feb 2016 01:47:15 -0500 (EST) Received: (qmail 6428 invoked from network); 1 Feb 2016 06:47:15 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 06:47:15 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E48A81C43A8; Sun, 31 Jan 2016 22:47:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers From: Mark Millard In-Reply-To: Date: Sun, 31 Jan 2016 22:47:08 -0800 Cc: Roman Divacky , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <1CCB483E-882A-4068-AF5B-EF43DAF0BA79@dsl-only.net> References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 06:47:12 -0000 More evidence: By adding "break raise" and then using "info frame" to = show the alignment at that point I can show that the later signal = delivery changes the alignment on the user process stack compared to = when raise was called. (Later I show the same for thr_kill.) > Breakpoint 2, __raise (s=3D29) at /usr/src/lib/libc/gen/raise.c:50 > warning: Source file is more recent than executable. > 50 if (__sys_thr_self(&id) =3D=3D -1) > (gdb) info frame > Stack level 0, frame at 0xffffdc90: > pc =3D 0x41904630 in __raise (/usr/src/lib/libc/gen/raise.c:50); = saved pc =3D 0x1800774 > called by frame at 0xffffdcb0 > source language c. > Arglist at 0xffffdc70, args: s=3D29 > Locals at 0xffffdc70, Previous frame's sp is 0xffffdc90 > Saved registers: > r29 at 0xffffdc84, r30 at 0xffffdc88, r31 at 0xffffdc8c, pc at = 0xffffdc94, lr at 0xffffdc94 > (gdb) cont > Continuing. >=20 > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006d0 in handler () > (gdb) info frame > Stack level 0, frame at 0xffffd71c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd71c > Arglist at 0xffffd6dc, args:=20 > Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > Saved registers: > r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 Note the difference (raise before delivery vs. handler via delivery): Frame at: 0x...90 vs. 0x...1c call by frame: 0x...b0 vs. 0x...1c Arglist at: 0x...70 vs. 0x...dc Locals at: 0x...70 vs. 0x...dc Previous frame's sp: 0x...90 vs. 0x...1c It looks like 4 additional pad bytes on the user/process stack are = needed to get back to alignment. [The span of addresses seems to be about: = 0xffffdc90-0xffffd6dc=3D=3D0x5B4=3D=3D1460 (raise's "frame at" minus = handler's "Locals at").] If I look at the frame for "break thr_kill" it also still shows an = aligned user/process stack before the delivery: > Breakpoint 3, 0x419046a0 in thr_kill () from /lib/libc.so.7 > (gdb) info frame > Stack level 0, frame at 0xffffdc70: > pc =3D 0x419046a0 in thr_kill; saved pc =3D 0x41904650 > called by frame at 0xffffdc90 > Arglist at 0xffffdc70, args:=20 > Locals at 0xffffdc70, Previous frame's sp is 0xffffdc70 (The relevant addresses are the same as raise showed.) Reminder of the source program structure that uses the potentially = frame/stack alignment sensitive libc/stdio library code: > # more sig_snprintf_use_test.c=20 > #include // for signal, SIGINFO, SIG_ERR, raise. > #include // for snprintf >=20 > void handler(int sig) > { > char buf[32]; > snprintf(buf, sizeof buf, "%d", sig); // FreeBSD's world does such > // things in some of its = handlers. > } >=20 > int main(void) > { > handler(0); // handler gets aligned stack frame for this; snprintf = works here. > if (signal(SIGINFO, handler) !=3D SIG_ERR) raise(SIGINFO); > // raise gets aligned stack frame; > // handler gets misaligned stack = frame; > // = snprintf/__vfrpintf/io_flush/__sfvwrite/memcpy: > // when built by clang 3.8.0 are = sensitive to > // the misalignment. > return 0; > } =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 9:12 PM, Mark Millard wrote: A summary of the later finding details for what I've done so far: It is system library code (__vfprintf and its inline io_flush call to = __sfvwrite) that may produce and use a potentially bad &iop->uio = address, depending the mix of how the calculation works and the = stack/frame alignment present in signal delivery. The gcc 4.2.1 vs. = clang 3.8.0 program status makes no difference to if it ends up with a = segmentation fault or not. When __vfprintf and its inline io_flush call to __sfvwrite is compiled = by gcc 4.2.1 --which always uses addition for offsets, voiding alignment = assumptions-- no variant of the program gets a segmentation fault. gcc = 4.2.1 does not create the dependency on the alignment that clang 3.8.0 = does. Yet the misalignment is present. (See the details.) When clang3.8.0 compiles __vfprintf and its inline io_flush call to = __sfvwrite --which uses masking for the offset in calculating &iop->uio, = making alignment assumptions-- every variant of the program gets a = segmentation fault. (The misalignment is still present.) The details for the misalignment evidence follow. For (C) "on a pure gcc 4.2.1 buildworld/buildkernel system". . . C0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt =20 > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd73c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd73c > Arglist at 0xffffd6fc, args:=20 > Locals at 0xffffd6fc, Previous frame's sp is 0xffffd73c > Saved registers: > r31 at 0xffffd738, pc at 0xffffd740, lr at 0xffffd740 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). In this case I also list __vfprintf's misalignment evidence for = reference: (break __vfprintf used.) > (gdb) info frame > Stack level 0, frame at 0xffffd57c: > pc =3D 0x41930af8 in __vfprintf = (/usr/src/lib/libc/stdio/vfprintf.c:452); saved pc =3D 0x41992e18 > called by frame at 0xffffd6fc > source language c. > Arglist at 0xffffd29c, args: fp=3D0xffffd5dc, locale=3D0x419c41e0 = <__xlocale_global_locale>, fmt0=3D0x1800a1c "%d", ap=3D0xffffd6cc > Locals at 0xffffd29c, Previous frame's sp is 0xffffd57c > Saved registers: > r30 at 0xffffd574, r31 at 0xffffd578, pc at 0xffffd580, lr at = 0xffffd580 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). Just to have one for reference, here is the "info frame" for the direct = handler call --which gets a properly aligned frame/stack: > (gdb) info frame > Stack level 0, frame at 0xffffdcc0: > pc =3D 0x18006e0 in handler; saved pc =3D 0x1800734 > called by frame at 0xffffdcd0 > Arglist at 0xffffdc80, args:=20 > Locals at 0xffffdc80, Previous frame's sp is 0xffffdcc0 > Saved registers: > r31 at 0xffffdcbc, pc at 0xffffdcc4, lr at 0xffffdcc4 Only the signal delivery is creating non-aligned stack frames. C1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > (gdb) info frame > Stack level 0, frame at 0xffffd70c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd70c > Arglist at 0xffffd6cc, args:=20 > Locals at 0xffffd6cc, Previous frame's sp is 0xffffd70c > Saved registers: > r31 at 0xffffd708, pc at 0xffffd710, lr at 0xffffd710 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). For (B) "on a clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix". . . B0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (B) context: This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd74c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd74c > Arglist at 0xffffd70c, args:=20 > Locals at 0xffffd70c, Previous frame's sp is 0xffffd74c > Saved registers: > r31 at 0xffffd748, pc at 0xffffd750, lr at 0xffffd750 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd714, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); B1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (B) context: (i.e., what I originally reported on and submitted a Bug report for) This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006d0 in handler () > (gdb) info frame > Stack level 0, frame at 0xffffd71c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd71c > Arglist at 0xffffd6dc, args:=20 > Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > Saved registers: > r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd6f4, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). More context notes. . . The "pure gcc 4.2.1 buildworld/buildkernel system" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r294960M: Wed Jan = 27 18:25:04 PST 2016 = root@FBSDG4C0:/usr/obj/gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODE= BUG powerpc 1100097 1100097 The "clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r294962M: Fri Jan = 29 18:28:17 PST 2016 = markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.powerpc/usr/src/sys/GENERI= Cvtsc-NODEBUG powerpc 1100097 1100097 (Same PowerMac, different SSD.) [I have renamed a.out's to indicate compiler context as I've gone = along.] [I copied each a.out to the other SSD for use after compiling/linking.] [I'm not generally showing the "direct call" properly aligned "info = frame" texts.] [handle SIGINFO nostop print pass; break handler used in gdb 7.10_5.] [For gcc 4.2.1 I used: gcc -std=3Dc99 -Wall sig_snprintf_use_test.c .] [For clang 3.8.0 I used: clang -std=3Dc11 -Wall -Wpedantic = sig_snprintf_use_test.c .] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 6:32 PM, Mark Millard wrote: > [I've never noticed gcc 4.2.1 generating code that was based on = presuming the alignment was present. For example: it always seems to use = addition to deal with address offsets, never masking. So I'd not expect = to see segmentation faults for that context even when the stack is = aligned modulo only 4. Separately checking the alignment is appropriate = for me to do.] >=20 > A) The reported context: >=20 > The kernel context here is a gcc 4.2.1 based buildkernel then = installkernel. > The world context here is a clang 3.8.0 based buildworld then = installworld. > The program context here is a clang 3.8.0 based: >=20 >> # clang -std=3Dc11 -Wall -Wpedantic sig_snprintf_use_test.c >> # /usr/local/bin/gdb a.out >=20 >=20 > Using "break handler" in gdb (7.10_5) and using "info frame" when it = stops for the "raise" shows the misalignment of the frame that the = handler was given ny the signal delivery. >=20 > By contrast the earlier direct call of the handler gets a "info frame" = result that shows the expected sort of alignment. >=20 > I find no evidence of frame/stack misalignment via gdb except for the = one that is created by the signal delivery. >=20 >=20 > B) I'll look at trying one or more of gcc 4.2.1, gcc49, gcc5 for the = program context, still based on a clang 3.8.0 buildworld and gcc 4.2.1 = buildkernel based on projects/clang380-import (-r294962). >=20 > C) I will look at trying the same program builds on a pure gcc 4.2.1 = buildworld/buildkernel context. (Likely 11.0-CURRENT -r294960.) >=20 >=20 > I'll send more results when I have them. >=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 5:50 PM, Justin Hibbits = wrote: Does this occur with gcc-built world and/or kernel? You could put some = printf()s in sendsig(), and there are KTR tracepoints already present. = The code assumes a fully aligned user stack, which should be correct, = but may not be. - Justin On Jan 31, 2016, at 6:41 PM, Mark Millard wrote: > I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import = stack alignment problem for TARGET_ARCH=3Dpowerpc signal delivery. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-31, at 6:08 AM, Roman Divacky = wrote: >=20 > Fwiw, LLVM expect 16B aligned stack on PowerPC. >=20 > On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: >> 3 quick FreeBSD for powerpc (32-bit) questions: >>=20 >>=20 >> A) For PowerPC (32-bit) what is the stack alignment requirement by = the ABI(s) that FreeBSD targets? >>=20 >> B) Are signal handlers supposed to be given that alignment? >>=20 >>=20 >> I ask because signal handlers are at times begin given just 4-byte = alignment but clang 3.8.0 powerpc's code generation can depend on the = alignment being more than 4. >>=20 >> clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 = relative to what would need to be an aligned address with alignment 8 or = more instead of adding 0x4 to a more arbitrary address. >>=20 >> So far I've only seen less than 8 byte stack alignment via signal = handler activity. >>=20 >>=20 >> C) Which should be blamed for problems here: clang's code generation, = FreeBSD's stack alignment handling for signals, or both? >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@freebsd.org Mon Feb 1 06:58:51 2016 Return-Path: Delivered-To: freebsd-ppc@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 0E4D3A74837 for ; Mon, 1 Feb 2016 06:58:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C601B13A7 for ; Mon, 1 Feb 2016 06:58:50 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12444 invoked from network); 1 Feb 2016 06:58:49 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 06:58:49 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 01 Feb 2016 01:58:44 -0500 (EST) Received: (qmail 8599 invoked from network); 1 Feb 2016 06:58:44 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 06:58:44 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id C682D1C43A8; Sun, 31 Jan 2016 22:58:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers From: Mark Millard In-Reply-To: <1CCB483E-882A-4068-AF5B-EF43DAF0BA79@dsl-only.net> Date: Sun, 31 Jan 2016 22:58:47 -0800 Cc: Roman Divacky , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <261D8A47-3B8A-4DE6-9D2C-F536C9143E84@dsl-only.net> References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> <1CCB483E-882A-4068-AF5B-EF43DAF0BA79@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 06:58:51 -0000 Just a correction to a sentence that I wrote. I had written: > Frame at: 0x...90 vs. 0x...1c > call by frame: 0x...b0 vs. 0x...1c > Arglist at: 0x...70 vs. 0x...dc > Locals at: 0x...70 vs. 0x...dc > Previous frame's sp: 0x...90 vs. 0x...1c >=20 > It looks like 4 additional pad bytes on the user/process stack are = needed to get back to alignment. Of course the figures on the right need to get smaller, not larger: The = stack grows towards smaller addresses. So to get to 0x...0 on the right = I should have said: It looks like 12 additional pad bytes on the user/process stack are = needed to get back to alignment. That would produce: Frame at: 0x...90 vs. 0x...10 call by frame: 0x...b0 vs. 0x...10 Arglist at: 0x...70 vs. 0x...d0 Locals at: 0x...70 vs. 0x...d0 Previous frame's sp: 0x...90 vs. 0x...10 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 10:47 PM, Mark Millard = wrote: More evidence: By adding "break raise" and then using "info frame" to = show the alignment at that point I can show that the later signal = delivery changes the alignment on the user process stack compared to = when raise was called. (Later I show the same for thr_kill.) > Breakpoint 2, __raise (s=3D29) at /usr/src/lib/libc/gen/raise.c:50 > warning: Source file is more recent than executable. > 50 if (__sys_thr_self(&id) =3D=3D -1) > (gdb) info frame > Stack level 0, frame at 0xffffdc90: > pc =3D 0x41904630 in __raise (/usr/src/lib/libc/gen/raise.c:50); saved = pc =3D 0x1800774 > called by frame at 0xffffdcb0 > source language c. > Arglist at 0xffffdc70, args: s=3D29 > Locals at 0xffffdc70, Previous frame's sp is 0xffffdc90 > Saved registers: > r29 at 0xffffdc84, r30 at 0xffffdc88, r31 at 0xffffdc8c, pc at = 0xffffdc94, lr at 0xffffdc94 > (gdb) cont > Continuing. >=20 > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006d0 in handler () > (gdb) info frame > Stack level 0, frame at 0xffffd71c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd71c > Arglist at 0xffffd6dc, args:=20 > Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > Saved registers: > r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 Note the difference (raise before delivery vs. handler via delivery): Frame at: 0x...90 vs. 0x...1c call by frame: 0x...b0 vs. 0x...1c Arglist at: 0x...70 vs. 0x...dc Locals at: 0x...70 vs. 0x...dc Previous frame's sp: 0x...90 vs. 0x...1c It looks like 4 additional pad bytes on the user/process stack are = needed to get back to alignment. [The span of addresses seems to be about: = 0xffffdc90-0xffffd6dc=3D=3D0x5B4=3D=3D1460 (raise's "frame at" minus = handler's "Locals at").] If I look at the frame for "break thr_kill" it also still shows an = aligned user/process stack before the delivery: > Breakpoint 3, 0x419046a0 in thr_kill () from /lib/libc.so.7 > (gdb) info frame > Stack level 0, frame at 0xffffdc70: > pc =3D 0x419046a0 in thr_kill; saved pc =3D 0x41904650 > called by frame at 0xffffdc90 > Arglist at 0xffffdc70, args:=20 > Locals at 0xffffdc70, Previous frame's sp is 0xffffdc70 (The relevant addresses are the same as raise showed.) Reminder of the source program structure that uses the potentially = frame/stack alignment sensitive libc/stdio library code: > # more sig_snprintf_use_test.c=20 > #include // for signal, SIGINFO, SIG_ERR, raise. > #include // for snprintf >=20 > void handler(int sig) > { > char buf[32]; > snprintf(buf, sizeof buf, "%d", sig); // FreeBSD's world does such > // things in some of its = handlers. > } >=20 > int main(void) > { > handler(0); // handler gets aligned stack frame for this; snprintf = works here. > if (signal(SIGINFO, handler) !=3D SIG_ERR) raise(SIGINFO); > // raise gets aligned stack frame; > // handler gets misaligned stack frame; > // = snprintf/__vfrpintf/io_flush/__sfvwrite/memcpy: > // when built by clang 3.8.0 are = sensitive to > // the misalignment. > return 0; > } =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 9:12 PM, Mark Millard wrote: A summary of the later finding details for what I've done so far: It is system library code (__vfprintf and its inline io_flush call to = __sfvwrite) that may produce and use a potentially bad &iop->uio = address, depending the mix of how the calculation works and the = stack/frame alignment present in signal delivery. The gcc 4.2.1 vs. = clang 3.8.0 program status makes no difference to if it ends up with a = segmentation fault or not. When __vfprintf and its inline io_flush call to __sfvwrite is compiled = by gcc 4.2.1 --which always uses addition for offsets, voiding alignment = assumptions-- no variant of the program gets a segmentation fault. gcc = 4.2.1 does not create the dependency on the alignment that clang 3.8.0 = does. Yet the misalignment is present. (See the details.) When clang3.8.0 compiles __vfprintf and its inline io_flush call to = __sfvwrite --which uses masking for the offset in calculating &iop->uio, = making alignment assumptions-- every variant of the program gets a = segmentation fault. (The misalignment is still present.) The details for the misalignment evidence follow. For (C) "on a pure gcc 4.2.1 buildworld/buildkernel system". . . C0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt =20 > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd73c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd73c > Arglist at 0xffffd6fc, args:=20 > Locals at 0xffffd6fc, Previous frame's sp is 0xffffd73c > Saved registers: > r31 at 0xffffd738, pc at 0xffffd740, lr at 0xffffd740 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). In this case I also list __vfprintf's misalignment evidence for = reference: (break __vfprintf used.) > (gdb) info frame > Stack level 0, frame at 0xffffd57c: > pc =3D 0x41930af8 in __vfprintf = (/usr/src/lib/libc/stdio/vfprintf.c:452); saved pc =3D 0x41992e18 > called by frame at 0xffffd6fc > source language c. > Arglist at 0xffffd29c, args: fp=3D0xffffd5dc, locale=3D0x419c41e0 = <__xlocale_global_locale>, fmt0=3D0x1800a1c "%d", ap=3D0xffffd6cc > Locals at 0xffffd29c, Previous frame's sp is 0xffffd57c > Saved registers: > r30 at 0xffffd574, r31 at 0xffffd578, pc at 0xffffd580, lr at = 0xffffd580 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). Just to have one for reference, here is the "info frame" for the direct = handler call --which gets a properly aligned frame/stack: > (gdb) info frame > Stack level 0, frame at 0xffffdcc0: > pc =3D 0x18006e0 in handler; saved pc =3D 0x1800734 > called by frame at 0xffffdcd0 > Arglist at 0xffffdc80, args:=20 > Locals at 0xffffdc80, Previous frame's sp is 0xffffdcc0 > Saved registers: > r31 at 0xffffdcbc, pc at 0xffffdcc4, lr at 0xffffdcc4 Only the signal delivery is creating non-aligned stack frames. C1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > (gdb) info frame > Stack level 0, frame at 0xffffd70c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd70c > Arglist at 0xffffd6cc, args:=20 > Locals at 0xffffd6cc, Previous frame's sp is 0xffffd70c > Saved registers: > r31 at 0xffffd708, pc at 0xffffd710, lr at 0xffffd710 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). For (B) "on a clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix". . . B0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (B) context: This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd74c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd74c > Arglist at 0xffffd70c, args:=20 > Locals at 0xffffd70c, Previous frame's sp is 0xffffd74c > Saved registers: > r31 at 0xffffd748, pc at 0xffffd750, lr at 0xffffd750 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd714, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); B1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (B) context: (i.e., what I originally reported on and submitted a Bug report for) This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006d0 in handler () > (gdb) info frame > Stack level 0, frame at 0xffffd71c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd71c > Arglist at 0xffffd6dc, args:=20 > Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > Saved registers: > r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd6f4, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). More context notes. . . The "pure gcc 4.2.1 buildworld/buildkernel system" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r294960M: Wed Jan = 27 18:25:04 PST 2016 = root@FBSDG4C0:/usr/obj/gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODE= BUG powerpc 1100097 1100097 The "clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r294962M: Fri Jan = 29 18:28:17 PST 2016 = markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.powerpc/usr/src/sys/GENERI= Cvtsc-NODEBUG powerpc 1100097 1100097 (Same PowerMac, different SSD.) [I have renamed a.out's to indicate compiler context as I've gone = along.] [I copied each a.out to the other SSD for use after compiling/linking.] [I'm not generally showing the "direct call" properly aligned "info = frame" texts.] [handle SIGINFO nostop print pass; break handler used in gdb 7.10_5.] [For gcc 4.2.1 I used: gcc -std=3Dc99 -Wall sig_snprintf_use_test.c .] [For clang 3.8.0 I used: clang -std=3Dc11 -Wall -Wpedantic = sig_snprintf_use_test.c .] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 6:32 PM, Mark Millard wrote: > [I've never noticed gcc 4.2.1 generating code that was based on = presuming the alignment was present. For example: it always seems to use = addition to deal with address offsets, never masking. So I'd not expect = to see segmentation faults for that context even when the stack is = aligned modulo only 4. Separately checking the alignment is appropriate = for me to do.] >=20 > A) The reported context: >=20 > The kernel context here is a gcc 4.2.1 based buildkernel then = installkernel. > The world context here is a clang 3.8.0 based buildworld then = installworld. > The program context here is a clang 3.8.0 based: >=20 >> # clang -std=3Dc11 -Wall -Wpedantic sig_snprintf_use_test.c >> # /usr/local/bin/gdb a.out >=20 >=20 > Using "break handler" in gdb (7.10_5) and using "info frame" when it = stops for the "raise" shows the misalignment of the frame that the = handler was given ny the signal delivery. >=20 > By contrast the earlier direct call of the handler gets a "info frame" = result that shows the expected sort of alignment. >=20 > I find no evidence of frame/stack misalignment via gdb except for the = one that is created by the signal delivery. >=20 >=20 > B) I'll look at trying one or more of gcc 4.2.1, gcc49, gcc5 for the = program context, still based on a clang 3.8.0 buildworld and gcc 4.2.1 = buildkernel based on projects/clang380-import (-r294962). >=20 > C) I will look at trying the same program builds on a pure gcc 4.2.1 = buildworld/buildkernel context. (Likely 11.0-CURRENT -r294960.) >=20 >=20 > I'll send more results when I have them. >=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 5:50 PM, Justin Hibbits = wrote: Does this occur with gcc-built world and/or kernel? You could put some = printf()s in sendsig(), and there are KTR tracepoints already present. = The code assumes a fully aligned user stack, which should be correct, = but may not be. - Justin On Jan 31, 2016, at 6:41 PM, Mark Millard wrote: > I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import = stack alignment problem for TARGET_ARCH=3Dpowerpc signal delivery. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-31, at 6:08 AM, Roman Divacky = wrote: >=20 > Fwiw, LLVM expect 16B aligned stack on PowerPC. >=20 > On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: >> 3 quick FreeBSD for powerpc (32-bit) questions: >>=20 >>=20 >> A) For PowerPC (32-bit) what is the stack alignment requirement by = the ABI(s) that FreeBSD targets? >>=20 >> B) Are signal handlers supposed to be given that alignment? >>=20 >>=20 >> I ask because signal handlers are at times begin given just 4-byte = alignment but clang 3.8.0 powerpc's code generation can depend on the = alignment being more than 4. >>=20 >> clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 = relative to what would need to be an aligned address with alignment 8 or = more instead of adding 0x4 to a more arbitrary address. >>=20 >> So far I've only seen less than 8 byte stack alignment via signal = handler activity. >>=20 >>=20 >> C) Which should be blamed for problems here: clang's code generation, = FreeBSD's stack alignment handling for signals, or both? >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@freebsd.org Mon Feb 1 08:11:20 2016 Return-Path: Delivered-To: freebsd-ppc@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 1BF66A7568A for ; Mon, 1 Feb 2016 08:11:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D3EA31865 for ; Mon, 1 Feb 2016 08:11:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22738 invoked from network); 1 Feb 2016 08:11:30 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 08:11:30 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 01 Feb 2016 03:11:23 -0500 (EST) Received: (qmail 1977 invoked from network); 1 Feb 2016 08:11:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Feb 2016 08:11:23 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 02E2A1C43A8; Mon, 1 Feb 2016 00:11:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers [the change that caused misaligned] From: Mark Millard In-Reply-To: <261D8A47-3B8A-4DE6-9D2C-F536C9143E84@dsl-only.net> Date: Mon, 1 Feb 2016 00:11:16 -0800 Cc: Roman Divacky , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> <1CCB483E-882A-4068-AF5B-EF43DAF0BA79@dsl-only.net> <261D8A47-3B8A-4DE6-9D2C-F536C9143E84@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 08:11:20 -0000 The -16/16 code below produced correct alignment but too little space. The -20/20 code below produces enough space but misalignment. To maintain 16-byte alignment while increasing the space would have = required going from -16/16 to -32/32. At least that is how I understand = this code. Index: sys/powerpc/powerpc/sigcode32.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/powerpc/powerpc/sigcode32.S = (.../head/sys/powerpc/powerpc/sigcode32.S) (revision 209975) +++ sys/powerpc/powerpc/sigcode32.S = (.../projects/clang380-import/sys/powerpc/powerpc/sigcode32.S) (working = copy) @@ -45,9 +45,9 @@ */ .globl CNAME(sigcode32),CNAME(szsigcode32) CNAME(sigcode32): - addi 1,1,-16 /* reserved space for callee */ + addi 1,1,-20 /* reserved space for callee */ blrl - addi 3,1,16+SF_UC /* restore sp, and get = &frame->sf_uc */ + addi 3,1,20+SF_UC /* restore sp, and get = &frame->sf_uc */ li 0,SYS_sigreturn sc /* sigreturn(scp) */ li 0,SYS_exit The "working copy" is -r266778 from 2014-May-27. -r209975 is from 2010-Jul-13. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 10:58 PM, Mark Millard = wrote: Just a correction to a sentence that I wrote. I had written: > Frame at: 0x...90 vs. 0x...1c > call by frame: 0x...b0 vs. 0x...1c > Arglist at: 0x...70 vs. 0x...dc > Locals at: 0x...70 vs. 0x...dc > Previous frame's sp: 0x...90 vs. 0x...1c >=20 > It looks like 4 additional pad bytes on the user/process stack are = needed to get back to alignment. Of course the figures on the right need to get smaller, not larger: The = stack grows towards smaller addresses. So to get to 0x...0 on the right = I should have said: It looks like 12 additional pad bytes on the user/process stack are = needed to get back to alignment. That would produce: Frame at: 0x...90 vs. 0x...10 call by frame: 0x...b0 vs. 0x...10 Arglist at: 0x...70 vs. 0x...d0 Locals at: 0x...70 vs. 0x...d0 Previous frame's sp: 0x...90 vs. 0x...10 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 10:47 PM, Mark Millard = wrote: More evidence: By adding "break raise" and then using "info frame" to = show the alignment at that point I can show that the later signal = delivery changes the alignment on the user process stack compared to = when raise was called. (Later I show the same for thr_kill.) > Breakpoint 2, __raise (s=3D29) at /usr/src/lib/libc/gen/raise.c:50 > warning: Source file is more recent than executable. > 50 if (__sys_thr_self(&id) =3D=3D -1) > (gdb) info frame > Stack level 0, frame at 0xffffdc90: > pc =3D 0x41904630 in __raise (/usr/src/lib/libc/gen/raise.c:50); saved = pc =3D 0x1800774 > called by frame at 0xffffdcb0 > source language c. > Arglist at 0xffffdc70, args: s=3D29 > Locals at 0xffffdc70, Previous frame's sp is 0xffffdc90 > Saved registers: > r29 at 0xffffdc84, r30 at 0xffffdc88, r31 at 0xffffdc8c, pc at = 0xffffdc94, lr at 0xffffdc94 > (gdb) cont > Continuing. >=20 > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006d0 in handler () > (gdb) info frame > Stack level 0, frame at 0xffffd71c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd71c > Arglist at 0xffffd6dc, args:=20 > Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > Saved registers: > r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 Note the difference (raise before delivery vs. handler via delivery): Frame at: 0x...90 vs. 0x...1c call by frame: 0x...b0 vs. 0x...1c Arglist at: 0x...70 vs. 0x...dc Locals at: 0x...70 vs. 0x...dc Previous frame's sp: 0x...90 vs. 0x...1c It looks like 4 additional pad bytes on the user/process stack are = needed to get back to alignment. [The span of addresses seems to be about: = 0xffffdc90-0xffffd6dc=3D=3D0x5B4=3D=3D1460 (raise's "frame at" minus = handler's "Locals at").] If I look at the frame for "break thr_kill" it also still shows an = aligned user/process stack before the delivery: > Breakpoint 3, 0x419046a0 in thr_kill () from /lib/libc.so.7 > (gdb) info frame > Stack level 0, frame at 0xffffdc70: > pc =3D 0x419046a0 in thr_kill; saved pc =3D 0x41904650 > called by frame at 0xffffdc90 > Arglist at 0xffffdc70, args:=20 > Locals at 0xffffdc70, Previous frame's sp is 0xffffdc70 (The relevant addresses are the same as raise showed.) Reminder of the source program structure that uses the potentially = frame/stack alignment sensitive libc/stdio library code: > # more sig_snprintf_use_test.c=20 > #include // for signal, SIGINFO, SIG_ERR, raise. > #include // for snprintf >=20 > void handler(int sig) > { > char buf[32]; > snprintf(buf, sizeof buf, "%d", sig); // FreeBSD's world does such > // things in some of its = handlers. > } >=20 > int main(void) > { > handler(0); // handler gets aligned stack frame for this; snprintf = works here. > if (signal(SIGINFO, handler) !=3D SIG_ERR) raise(SIGINFO); > // raise gets aligned stack frame; > // handler gets misaligned stack frame; > // = snprintf/__vfrpintf/io_flush/__sfvwrite/memcpy: > // when built by clang 3.8.0 are = sensitive to > // the misalignment. > return 0; > } =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 9:12 PM, Mark Millard wrote: A summary of the later finding details for what I've done so far: It is system library code (__vfprintf and its inline io_flush call to = __sfvwrite) that may produce and use a potentially bad &iop->uio = address, depending the mix of how the calculation works and the = stack/frame alignment present in signal delivery. The gcc 4.2.1 vs. = clang 3.8.0 program status makes no difference to if it ends up with a = segmentation fault or not. When __vfprintf and its inline io_flush call to __sfvwrite is compiled = by gcc 4.2.1 --which always uses addition for offsets, voiding alignment = assumptions-- no variant of the program gets a segmentation fault. gcc = 4.2.1 does not create the dependency on the alignment that clang 3.8.0 = does. Yet the misalignment is present. (See the details.) When clang3.8.0 compiles __vfprintf and its inline io_flush call to = __sfvwrite --which uses masking for the offset in calculating &iop->uio, = making alignment assumptions-- every variant of the program gets a = segmentation fault. (The misalignment is still present.) The details for the misalignment evidence follow. For (C) "on a pure gcc 4.2.1 buildworld/buildkernel system". . . C0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt =20 > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd73c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd73c > Arglist at 0xffffd6fc, args:=20 > Locals at 0xffffd6fc, Previous frame's sp is 0xffffd73c > Saved registers: > r31 at 0xffffd738, pc at 0xffffd740, lr at 0xffffd740 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). In this case I also list __vfprintf's misalignment evidence for = reference: (break __vfprintf used.) > (gdb) info frame > Stack level 0, frame at 0xffffd57c: > pc =3D 0x41930af8 in __vfprintf = (/usr/src/lib/libc/stdio/vfprintf.c:452); saved pc =3D 0x41992e18 > called by frame at 0xffffd6fc > source language c. > Arglist at 0xffffd29c, args: fp=3D0xffffd5dc, locale=3D0x419c41e0 = <__xlocale_global_locale>, fmt0=3D0x1800a1c "%d", ap=3D0xffffd6cc > Locals at 0xffffd29c, Previous frame's sp is 0xffffd57c > Saved registers: > r30 at 0xffffd574, r31 at 0xffffd578, pc at 0xffffd580, lr at = 0xffffd580 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). Just to have one for reference, here is the "info frame" for the direct = handler call --which gets a properly aligned frame/stack: > (gdb) info frame > Stack level 0, frame at 0xffffdcc0: > pc =3D 0x18006e0 in handler; saved pc =3D 0x1800734 > called by frame at 0xffffdcd0 > Arglist at 0xffffdc80, args:=20 > Locals at 0xffffdc80, Previous frame's sp is 0xffffdcc0 > Saved registers: > r31 at 0xffffdcbc, pc at 0xffffdcc4, lr at 0xffffdcc4 Only the signal delivery is creating non-aligned stack frames. C1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > (gdb) info frame > Stack level 0, frame at 0xffffd70c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd70c > Arglist at 0xffffd6cc, args:=20 > Locals at 0xffffd6cc, Previous frame's sp is 0xffffd70c > Saved registers: > r31 at 0xffffd708, pc at 0xffffd710, lr at 0xffffd710 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). For (B) "on a clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix". . . B0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (B) context: This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd74c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd74c > Arglist at 0xffffd70c, args:=20 > Locals at 0xffffd70c, Previous frame's sp is 0xffffd74c > Saved registers: > r31 at 0xffffd748, pc at 0xffffd750, lr at 0xffffd750 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd714, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); B1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (B) context: (i.e., what I originally reported on and submitted a Bug report for) This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006d0 in handler () > (gdb) info frame > Stack level 0, frame at 0xffffd71c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd71c > Arglist at 0xffffd6dc, args:=20 > Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > Saved registers: > r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd6f4, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). More context notes. . . The "pure gcc 4.2.1 buildworld/buildkernel system" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r294960M: Wed Jan = 27 18:25:04 PST 2016 = root@FBSDG4C0:/usr/obj/gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODE= BUG powerpc 1100097 1100097 The "clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r294962M: Fri Jan = 29 18:28:17 PST 2016 = markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.powerpc/usr/src/sys/GENERI= Cvtsc-NODEBUG powerpc 1100097 1100097 (Same PowerMac, different SSD.) [I have renamed a.out's to indicate compiler context as I've gone = along.] [I copied each a.out to the other SSD for use after compiling/linking.] [I'm not generally showing the "direct call" properly aligned "info = frame" texts.] [handle SIGINFO nostop print pass; break handler used in gdb 7.10_5.] [For gcc 4.2.1 I used: gcc -std=3Dc99 -Wall sig_snprintf_use_test.c .] [For clang 3.8.0 I used: clang -std=3Dc11 -Wall -Wpedantic = sig_snprintf_use_test.c .] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 6:32 PM, Mark Millard wrote: > [I've never noticed gcc 4.2.1 generating code that was based on = presuming the alignment was present. For example: it always seems to use = addition to deal with address offsets, never masking. So I'd not expect = to see segmentation faults for that context even when the stack is = aligned modulo only 4. Separately checking the alignment is appropriate = for me to do.] >=20 > A) The reported context: >=20 > The kernel context here is a gcc 4.2.1 based buildkernel then = installkernel. > The world context here is a clang 3.8.0 based buildworld then = installworld. > The program context here is a clang 3.8.0 based: >=20 >> # clang -std=3Dc11 -Wall -Wpedantic sig_snprintf_use_test.c >> # /usr/local/bin/gdb a.out >=20 >=20 > Using "break handler" in gdb (7.10_5) and using "info frame" when it = stops for the "raise" shows the misalignment of the frame that the = handler was given ny the signal delivery. >=20 > By contrast the earlier direct call of the handler gets a "info frame" = result that shows the expected sort of alignment. >=20 > I find no evidence of frame/stack misalignment via gdb except for the = one that is created by the signal delivery. >=20 >=20 > B) I'll look at trying one or more of gcc 4.2.1, gcc49, gcc5 for the = program context, still based on a clang 3.8.0 buildworld and gcc 4.2.1 = buildkernel based on projects/clang380-import (-r294962). >=20 > C) I will look at trying the same program builds on a pure gcc 4.2.1 = buildworld/buildkernel context. (Likely 11.0-CURRENT -r294960.) >=20 >=20 > I'll send more results when I have them. >=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 5:50 PM, Justin Hibbits = wrote: Does this occur with gcc-built world and/or kernel? You could put some = printf()s in sendsig(), and there are KTR tracepoints already present. = The code assumes a fully aligned user stack, which should be correct, = but may not be. - Justin On Jan 31, 2016, at 6:41 PM, Mark Millard wrote: > I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import = stack alignment problem for TARGET_ARCH=3Dpowerpc signal delivery. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-31, at 6:08 AM, Roman Divacky = wrote: >=20 > Fwiw, LLVM expect 16B aligned stack on PowerPC. >=20 > On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: >> 3 quick FreeBSD for powerpc (32-bit) questions: >>=20 >>=20 >> A) For PowerPC (32-bit) what is the stack alignment requirement by = the ABI(s) that FreeBSD targets? >>=20 >> B) Are signal handlers supposed to be given that alignment? >>=20 >>=20 >> I ask because signal handlers are at times begin given just 4-byte = alignment but clang 3.8.0 powerpc's code generation can depend on the = alignment being more than 4. >>=20 >> clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 = relative to what would need to be an aligned address with alignment 8 or = more instead of adding 0x4 to a more arbitrary address. >>=20 >> So far I've only seen less than 8 byte stack alignment via signal = handler activity. >>=20 >>=20 >> C) Which should be blamed for problems here: clang's code generation, = FreeBSD's stack alignment handling for signals, or both? >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@freebsd.org Tue Feb 2 03:32:51 2016 Return-Path: Delivered-To: freebsd-ppc@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 C99EFA73F21 for ; Tue, 2 Feb 2016 03:32:51 +0000 (UTC) (envelope-from admin192@d41.amazon3-2016sale.com) Received: from d41.amazon3-2016sale.com (d41.amazon3-2016sale.com [157.52.233.192]) by mx1.freebsd.org (Postfix) with ESMTP id B911FFD9 for ; Tue, 2 Feb 2016 03:32:49 +0000 (UTC) (envelope-from admin192@d41.amazon3-2016sale.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=amazon3-2016sale; d=d41.amazon3-2016sale.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=admin192@d41.amazon3-2016sale.com; bh=ey49/roQihm/3nkb4dJv1LGbOac=; b=AWC2ctav8iXjqQGnjdzXLh5AywvyyE1Nwl8CWzI8nMu8hyuAvoET0Z6pVP2a65jOxztoi1tO1IVT PeQV9oTCe512VboiIblQ2dZ9Idumem71n0eZXXBlnrpvFZhxaNYVP3jfjwVowdoEEX+csLURpLcz ywg+3jFeXI9Qtz8aQHU= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=amazon3-2016sale; d=d41.amazon3-2016sale.com; b=FROF0Q6ja93i+1rwfu8SE9tlmoq52Q+mE5hvN8cKOtvCcSp/0d/fbCfnR46ppDDcIYr9T+xZAiK1 KOQHUf1HfAYmhBUqtM9JzqslYb9Bfb44Bh2D/mEsX8+FSR+gGKeh+fc1H1CxDUtsHXf3sXfFqW2B AoKtIq+bIOedPHSZ08Y=; From: "Pandora Jewelry" To: freebsd-ppc@freebsd.org Date: 2 Feb 2016 11:22:45 +0800 Subject: Important:Bundle Up! Valentine's Day Special REWARDS Only For You491 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 03:32:51 -0000 From owner-freebsd-ppc@freebsd.org Tue Feb 2 09:48:53 2016 Return-Path: Delivered-To: freebsd-ppc@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 EB532A98652 for ; Tue, 2 Feb 2016 09:48:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE18E1D05 for ; Tue, 2 Feb 2016 09:48:52 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 3944 invoked from network); 2 Feb 2016 09:48:58 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 2 Feb 2016 09:48:58 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 02 Feb 2016 04:48:48 -0500 (EST) Received: (qmail 24814 invoked from network); 2 Feb 2016 09:48:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 2 Feb 2016 09:48:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D52781C43C6; Tue, 2 Feb 2016 01:48:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers [the change that caused misaligned] From: Mark Millard In-Reply-To: Date: Tue, 2 Feb 2016 01:48:43 -0800 Cc: Roman Divacky , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8D38E67E-B798-4EFD-951F-DADFDBAEDD8A@dsl-only.net> References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> <1CCB483E-882A-4068-AF5B-EF43DAF0BA79@dsl-only.net> <261D8A47-3B8A-4DE6-9D2C-F536C9143E84@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 09:48:53 -0000 I tried the change to -32 and 32 (from -20 and 20) on/for the powerpc = (32-bit) PowerMac that I use and the results were: A) "info frame" in gdb shows signal handlers are now started with = 16-byte aligned stack frames. (Applies to gcc 4.2.1 based contexts too, = not just to the clang 3.8.0 ones with the __vfprintf-tied segmentation = faults during signals.) and. . . B) The "clang 3.8.0 compiled __vfprintf" segmentation faults in = libc/stdio library code during signal handlers that use such code no = longer happen because the alignment matches the code requirements. I've added this information to Bug 206810. (Note: There are a couple of segmentation fault contexts that I've never = tied down to any specific property: no discovered evidence of signal = handler involvement or of __vfprintf involvement, for example. These are = still a problem. But where I had tied the faults to signal handlers = using __vfprintf now instead work fine in my experimental clang 3.8.0 = based builds.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-1, at 12:11 AM, Mark Millard wrote: The -16/16 code below produced correct alignment but too little space. The -20/20 code below produces enough space but misalignment. To maintain 16-byte alignment while increasing the space would have = required going from -16/16 to -32/32. At least that is how I understand = this code. > Index: sys/powerpc/powerpc/sigcode32.S > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/powerpc/powerpc/sigcode32.S = (.../head/sys/powerpc/powerpc/sigcode32.S) (revision 209975) > +++ sys/powerpc/powerpc/sigcode32.S = (.../projects/clang380-import/sys/powerpc/powerpc/sigcode32.S) (working = copy) > @@ -45,9 +45,9 @@ > */ > .globl CNAME(sigcode32),CNAME(szsigcode32) > CNAME(sigcode32): > - addi 1,1,-16 /* reserved space for callee = */ > + addi 1,1,-20 /* reserved space for callee = */ > blrl > - addi 3,1,16+SF_UC /* restore sp, and get = &frame->sf_uc */ > + addi 3,1,20+SF_UC /* restore sp, and get = &frame->sf_uc */ > li 0,SYS_sigreturn > sc /* sigreturn(scp) */ > li 0,SYS_exit The "working copy" is -r266778 from 2014-May-27. -r209975 is from 2010-Jul-13. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 10:58 PM, Mark Millard = wrote: Just a correction to a sentence that I wrote. I had written: > Frame at: 0x...90 vs. 0x...1c > call by frame: 0x...b0 vs. 0x...1c > Arglist at: 0x...70 vs. 0x...dc > Locals at: 0x...70 vs. 0x...dc > Previous frame's sp: 0x...90 vs. 0x...1c >=20 > It looks like 4 additional pad bytes on the user/process stack are = needed to get back to alignment. Of course the figures on the right need to get smaller, not larger: The = stack grows towards smaller addresses. So to get to 0x...0 on the right = I should have said: It looks like 12 additional pad bytes on the user/process stack are = needed to get back to alignment. That would produce: Frame at: 0x...90 vs. 0x...10 call by frame: 0x...b0 vs. 0x...10 Arglist at: 0x...70 vs. 0x...d0 Locals at: 0x...70 vs. 0x...d0 Previous frame's sp: 0x...90 vs. 0x...10 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 10:47 PM, Mark Millard = wrote: More evidence: By adding "break raise" and then using "info frame" to = show the alignment at that point I can show that the later signal = delivery changes the alignment on the user process stack compared to = when raise was called. (Later I show the same for thr_kill.) > Breakpoint 2, __raise (s=3D29) at /usr/src/lib/libc/gen/raise.c:50 > warning: Source file is more recent than executable. > 50 if (__sys_thr_self(&id) =3D=3D -1) > (gdb) info frame > Stack level 0, frame at 0xffffdc90: > pc =3D 0x41904630 in __raise (/usr/src/lib/libc/gen/raise.c:50); saved = pc =3D 0x1800774 > called by frame at 0xffffdcb0 > source language c. > Arglist at 0xffffdc70, args: s=3D29 > Locals at 0xffffdc70, Previous frame's sp is 0xffffdc90 > Saved registers: > r29 at 0xffffdc84, r30 at 0xffffdc88, r31 at 0xffffdc8c, pc at = 0xffffdc94, lr at 0xffffdc94 > (gdb) cont > Continuing. >=20 > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006d0 in handler () > (gdb) info frame > Stack level 0, frame at 0xffffd71c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd71c > Arglist at 0xffffd6dc, args:=20 > Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > Saved registers: > r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 Note the difference (raise before delivery vs. handler via delivery): Frame at: 0x...90 vs. 0x...1c call by frame: 0x...b0 vs. 0x...1c Arglist at: 0x...70 vs. 0x...dc Locals at: 0x...70 vs. 0x...dc Previous frame's sp: 0x...90 vs. 0x...1c It looks like 4 additional pad bytes on the user/process stack are = needed to get back to alignment. [The span of addresses seems to be about: = 0xffffdc90-0xffffd6dc=3D=3D0x5B4=3D=3D1460 (raise's "frame at" minus = handler's "Locals at").] If I look at the frame for "break thr_kill" it also still shows an = aligned user/process stack before the delivery: > Breakpoint 3, 0x419046a0 in thr_kill () from /lib/libc.so.7 > (gdb) info frame > Stack level 0, frame at 0xffffdc70: > pc =3D 0x419046a0 in thr_kill; saved pc =3D 0x41904650 > called by frame at 0xffffdc90 > Arglist at 0xffffdc70, args:=20 > Locals at 0xffffdc70, Previous frame's sp is 0xffffdc70 (The relevant addresses are the same as raise showed.) Reminder of the source program structure that uses the potentially = frame/stack alignment sensitive libc/stdio library code: > # more sig_snprintf_use_test.c=20 > #include // for signal, SIGINFO, SIG_ERR, raise. > #include // for snprintf >=20 > void handler(int sig) > { > char buf[32]; > snprintf(buf, sizeof buf, "%d", sig); // FreeBSD's world does such > // things in some of its = handlers. > } >=20 > int main(void) > { > handler(0); // handler gets aligned stack frame for this; snprintf = works here. > if (signal(SIGINFO, handler) !=3D SIG_ERR) raise(SIGINFO); > // raise gets aligned stack frame; > // handler gets misaligned stack frame; > // = snprintf/__vfrpintf/io_flush/__sfvwrite/memcpy: > // when built by clang 3.8.0 are = sensitive to > // the misalignment. > return 0; > } =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 9:12 PM, Mark Millard wrote: A summary of the later finding details for what I've done so far: It is system library code (__vfprintf and its inline io_flush call to = __sfvwrite) that may produce and use a potentially bad &iop->uio = address, depending the mix of how the calculation works and the = stack/frame alignment present in signal delivery. The gcc 4.2.1 vs. = clang 3.8.0 program status makes no difference to if it ends up with a = segmentation fault or not. When __vfprintf and its inline io_flush call to __sfvwrite is compiled = by gcc 4.2.1 --which always uses addition for offsets, voiding alignment = assumptions-- no variant of the program gets a segmentation fault. gcc = 4.2.1 does not create the dependency on the alignment that clang 3.8.0 = does. Yet the misalignment is present. (See the details.) When clang3.8.0 compiles __vfprintf and its inline io_flush call to = __sfvwrite --which uses masking for the offset in calculating &iop->uio, = making alignment assumptions-- every variant of the program gets a = segmentation fault. (The misalignment is still present.) The details for the misalignment evidence follow. For (C) "on a pure gcc 4.2.1 buildworld/buildkernel system". . . C0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt =20 > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd73c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd73c > Arglist at 0xffffd6fc, args:=20 > Locals at 0xffffd6fc, Previous frame's sp is 0xffffd73c > Saved registers: > r31 at 0xffffd738, pc at 0xffffd740, lr at 0xffffd740 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). In this case I also list __vfprintf's misalignment evidence for = reference: (break __vfprintf used.) > (gdb) info frame > Stack level 0, frame at 0xffffd57c: > pc =3D 0x41930af8 in __vfprintf = (/usr/src/lib/libc/stdio/vfprintf.c:452); saved pc =3D 0x41992e18 > called by frame at 0xffffd6fc > source language c. > Arglist at 0xffffd29c, args: fp=3D0xffffd5dc, locale=3D0x419c41e0 = <__xlocale_global_locale>, fmt0=3D0x1800a1c "%d", ap=3D0xffffd6cc > Locals at 0xffffd29c, Previous frame's sp is 0xffffd57c > Saved registers: > r30 at 0xffffd574, r31 at 0xffffd578, pc at 0xffffd580, lr at = 0xffffd580 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). Just to have one for reference, here is the "info frame" for the direct = handler call --which gets a properly aligned frame/stack: > (gdb) info frame > Stack level 0, frame at 0xffffdcc0: > pc =3D 0x18006e0 in handler; saved pc =3D 0x1800734 > called by frame at 0xffffdcd0 > Arglist at 0xffffdc80, args:=20 > Locals at 0xffffdc80, Previous frame's sp is 0xffffdcc0 > Saved registers: > r31 at 0xffffdcbc, pc at 0xffffdcc4, lr at 0xffffdcc4 Only the signal delivery is creating non-aligned stack frames. C1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (C) context: This *has* a misaligned signal delivery stack but there is no = segmentation fault. > (gdb) info frame > Stack level 0, frame at 0xffffd70c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd70c > Arglist at 0xffffd6cc, args:=20 > Locals at 0xffffd6cc, Previous frame's sp is 0xffffd70c > Saved registers: > r31 at 0xffffd708, pc at 0xffffd710, lr at 0xffffd710 So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at", "Arglist", "Locals", and "Previous frame's = sp" (which is listed as the same as "frame at"). For (B) "on a clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix". . . B0) For gcc421-a.out gets signal delivery to its handler: "info frame" = in this (B) context: This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006e0 in handler () > (gdb) bt > #0 0x018006e0 in handler () > #1 > #2 0x00000000 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffd74c: > pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd74c > Arglist at 0xffffd70c, args:=20 > Locals at 0xffffd70c, Previous frame's sp is 0xffffd74c > Saved registers: > r31 at 0xffffd748, pc at 0xffffd750, lr at 0xffffd750 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd714, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); B1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (B) context: (i.e., what I originally reported on and submitted a Bug report for) This *has* a misaligned signal delivery stack and there *is* a = segmentation fault. > Program received signal SIGINFO, Information request. >=20 > Breakpoint 1, 0x018006d0 in handler () > (gdb) info frame > Stack level 0, frame at 0xffffd71c: > pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 > called by frame at 0xffffd71c > Arglist at 0xffffd6dc, args:=20 > Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > Saved registers: > r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 > (gdb) cont > Continuing. >=20 > Program received signal SIGSEGV, Segmentation fault. > 0x419a89c8 in memcpy (dst0=3D0xffffd6f4, src0=3D, = length=3D) at /usr/src/lib/libc/string/bcopy.c:124 > warning: Source file is more recent than executable. > 124 TLOOP1(*--dst =3D *--src); So misaligned (multiple of 4 but of no higher power of 2) for "frame = at", "called by frame at" (which is listed as the same as "frame at"), = "Arglist", "Locals", and "Previous frame's sp" (which is listed as the = same as "frame at"). More context notes. . . The "pure gcc 4.2.1 buildworld/buildkernel system" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r294960M: Wed Jan = 27 18:25:04 PST 2016 = root@FBSDG4C0:/usr/obj/gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODE= BUG powerpc 1100097 1100097 The "clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix" has: # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r294962M: Fri Jan = 29 18:28:17 PST 2016 = markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.powerpc/usr/src/sys/GENERI= Cvtsc-NODEBUG powerpc 1100097 1100097 (Same PowerMac, different SSD.) [I have renamed a.out's to indicate compiler context as I've gone = along.] [I copied each a.out to the other SSD for use after compiling/linking.] [I'm not generally showing the "direct call" properly aligned "info = frame" texts.] [handle SIGINFO nostop print pass; break handler used in gdb 7.10_5.] [For gcc 4.2.1 I used: gcc -std=3Dc99 -Wall sig_snprintf_use_test.c .] [For clang 3.8.0 I used: clang -std=3Dc11 -Wall -Wpedantic = sig_snprintf_use_test.c .] =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 6:32 PM, Mark Millard wrote: > [I've never noticed gcc 4.2.1 generating code that was based on = presuming the alignment was present. For example: it always seems to use = addition to deal with address offsets, never masking. So I'd not expect = to see segmentation faults for that context even when the stack is = aligned modulo only 4. Separately checking the alignment is appropriate = for me to do.] >=20 > A) The reported context: >=20 > The kernel context here is a gcc 4.2.1 based buildkernel then = installkernel. > The world context here is a clang 3.8.0 based buildworld then = installworld. > The program context here is a clang 3.8.0 based: >=20 >> # clang -std=3Dc11 -Wall -Wpedantic sig_snprintf_use_test.c >> # /usr/local/bin/gdb a.out >=20 >=20 > Using "break handler" in gdb (7.10_5) and using "info frame" when it = stops for the "raise" shows the misalignment of the frame that the = handler was given ny the signal delivery. >=20 > By contrast the earlier direct call of the handler gets a "info frame" = result that shows the expected sort of alignment. >=20 > I find no evidence of frame/stack misalignment via gdb except for the = one that is created by the signal delivery. >=20 >=20 > B) I'll look at trying one or more of gcc 4.2.1, gcc49, gcc5 for the = program context, still based on a clang 3.8.0 buildworld and gcc 4.2.1 = buildkernel based on projects/clang380-import (-r294962). >=20 > C) I will look at trying the same program builds on a pure gcc 4.2.1 = buildworld/buildkernel context. (Likely 11.0-CURRENT -r294960.) >=20 >=20 > I'll send more results when I have them. >=20 >=20 =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Jan-31, at 5:50 PM, Justin Hibbits = wrote: Does this occur with gcc-built world and/or kernel? You could put some = printf()s in sendsig(), and there are KTR tracepoints already present. = The code assumes a fully aligned user stack, which should be correct, = but may not be. - Justin On Jan 31, 2016, at 6:41 PM, Mark Millard wrote: > I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import = stack alignment problem for TARGET_ARCH=3Dpowerpc signal delivery. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Jan-31, at 6:08 AM, Roman Divacky = wrote: >=20 > Fwiw, LLVM expect 16B aligned stack on PowerPC. >=20 > On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: >> 3 quick FreeBSD for powerpc (32-bit) questions: >>=20 >>=20 >> A) For PowerPC (32-bit) what is the stack alignment requirement by = the ABI(s) that FreeBSD targets? >>=20 >> B) Are signal handlers supposed to be given that alignment? >>=20 >>=20 >> I ask because signal handlers are at times begin given just 4-byte = alignment but clang 3.8.0 powerpc's code generation can depend on the = alignment being more than 4. >>=20 >> clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 = relative to what would need to be an aligned address with alignment 8 or = more instead of adding 0x4 to a more arbitrary address. >>=20 >> So far I've only seen less than 8 byte stack alignment via signal = handler activity. >>=20 >>=20 >> C) Which should be blamed for problems here: clang's code generation, = FreeBSD's stack alignment handling for signals, or both? >>=20 >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" >=20 From owner-freebsd-ppc@freebsd.org Tue Feb 2 16:05:17 2016 Return-Path: Delivered-To: freebsd-ppc@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 B5657A98118; Tue, 2 Feb 2016 16:05:17 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CCE21116; Tue, 2 Feb 2016 16:05:17 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-oi0-x22b.google.com with SMTP id r14so114978218oie.0; Tue, 02 Feb 2016 08:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DQPO9YCEzBejT5idsDIJnfKBiyO/UvI5GioIT8pmHCM=; b=02MWqTmt4v7QvKWEX8hiBpO5IBc4LIQWjbyzJjgr/nW41bpzEg4b6yEUV86nMQV1Lw FtzQcQ4VewK+cH9TOp6xEZ0ndxn82mLxZXFepJWvE+ib9Z9ZPnzTd+ZtvYKjeewBnfqd YXvWby4KOE02ffZX7BsEyRdSTeZL8ofFd7+A2gdn32HXyvZum8A/jkDhMfpG2Zvnpdg/ 2dYMCmGtBgSsFEhi2Zd2Zxxh7VNnpl9zhfM8dygpdwRPHaKhI39ytRpuqnodz8Fqj5Gk /LI5HlUNgU3uqxQxdFwTTX7BZeo1sq8UyHdG6WZbFKlnJ4eEJ6Jbd2FPPJKYxgem0+F0 IoMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DQPO9YCEzBejT5idsDIJnfKBiyO/UvI5GioIT8pmHCM=; b=TyM45TCxd2c/RsP9pUXRYszXgT0MUm8Pipida8ELiitIah8Wgszt0+ZX2ZK34ayTLF t6fYYs2A4/ODZJ6XFA976h5t6aBADa7S/VwmgMjdVXeYiGjpgomki4JQq9lxgSxBJPDh pSEvx2M327o6V4fNJpi9L4d+3NGQrXUvAv2lndZvg8Z3JhWdGy9RqeoWhv7Dn5lCLyZK pzEtARaguOp9e+nhNJgEvPe4PtdOHMqxZmjBRx2pZiyMLssb96uu9MVx7D7SDbXOF08q GcAD32xSBQ+YVXXvbul4lD4QzlHj+Ow1KPw7O6czVpN6RTVsPF44qYJQFrXFnK+GtKlm dGkw== X-Gm-Message-State: AG10YOQ6D1Kya9WX5VOh+OqlnNymwSgPd+NW73Kaj/EiQRerej0pWYZNYXWlDlpPxheyhS82wocjwsx1H4T+ZA== MIME-Version: 1.0 X-Received: by 10.202.195.78 with SMTP id t75mr7015281oif.26.1454429116660; Tue, 02 Feb 2016 08:05:16 -0800 (PST) Received: by 10.182.74.101 with HTTP; Tue, 2 Feb 2016 08:05:16 -0800 (PST) In-Reply-To: <8D38E67E-B798-4EFD-951F-DADFDBAEDD8A@dsl-only.net> References: <517B7923-5166-42D0-8FA8-52C05F956F06@dsl-only.net> <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> <1CCB483E-882A-4068-AF5B-EF43DAF0BA79@dsl-only.net> <261D8A47-3B8A-4DE6-9D2C-F536C9143E84@dsl-only.net> <8D38E67E-B798-4EFD-951F-DADFDBAEDD8A@dsl-only.net> Date: Tue, 2 Feb 2016 10:05:16 -0600 Message-ID: Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers [the change that caused misaligned] From: Justin Hibbits To: Mark Millard Cc: Roman Divacky , Nathan Whitehorn , FreeBSD Toolchain , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 16:05:17 -0000 Good catch! I'll commit the change tonight. - Justin On Tue, Feb 2, 2016 at 3:48 AM, Mark Millard wrote: > I tried the change to -32 and 32 (from -20 and 20) on/for the powerpc (32= -bit) PowerMac that I use and the results were: > > A) "info frame" in gdb shows signal handlers are now started with 16-byte= aligned stack frames. (Applies to gcc 4.2.1 based contexts too, not just t= o the clang 3.8.0 ones with the __vfprintf-tied segmentation faults during = signals.) > > and. . . > > B) The "clang 3.8.0 compiled __vfprintf" segmentation faults in libc/stdi= o library code during signal handlers that use such code no longer happen b= ecause the alignment matches the code requirements. > > I've added this information to Bug 206810. > > > (Note: There are a couple of segmentation fault contexts that I've never = tied down to any specific property: no discovered evidence of signal handle= r involvement or of __vfprintf involvement, for example. These are still a = problem. But where I had tied the faults to signal handlers using __vfprint= f now instead work fine in my experimental clang 3.8.0 based builds.) > > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > On 2016-Feb-1, at 12:11 AM, Mark Millard wrote: > > The -16/16 code below produced correct alignment but too little space. > > The -20/20 code below produces enough space but misalignment. > > To maintain 16-byte alignment while increasing the space would have requi= red going from -16/16 to -32/32. At least that is how I understand this cod= e. > > >> Index: sys/powerpc/powerpc/sigcode32.S >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- sys/powerpc/powerpc/sigcode32.S (.../head/sys/powerpc/powerpc/si= gcode32.S) (revision 209975) >> +++ sys/powerpc/powerpc/sigcode32.S (.../projects/clang380-import/sy= s/powerpc/powerpc/sigcode32.S) (working copy) >> @@ -45,9 +45,9 @@ >> */ >> .globl CNAME(sigcode32),CNAME(szsigcode32) >> CNAME(sigcode32): >> - addi 1,1,-16 /* reserved space for callee */ >> + addi 1,1,-20 /* reserved space for callee */ >> blrl >> - addi 3,1,16+SF_UC /* restore sp, and get &frame->s= f_uc */ >> + addi 3,1,20+SF_UC /* restore sp, and get &frame->s= f_uc */ >> li 0,SYS_sigreturn >> sc /* sigreturn(scp) */ >> li 0,SYS_exit > > > > The "working copy" is -r266778 from 2014-May-27. > > -r209975 is from 2010-Jul-13. > > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > On 2016-Jan-31, at 10:58 PM, Mark Millard wrote: > > Just a correction to a sentence that I wrote. I had written: > >> Frame at: 0x...90 vs. 0x...1c >> call by frame: 0x...b0 vs. 0x...1c >> Arglist at: 0x...70 vs. 0x...dc >> Locals at: 0x...70 vs. 0x...dc >> Previous frame's sp: 0x...90 vs. 0x...1c >> >> It looks like 4 additional pad bytes on the user/process stack are neede= d to get back to alignment. > > Of course the figures on the right need to get smaller, not larger: The s= tack grows towards smaller addresses. So to get to 0x...0 on the right I sh= ould have said: > > It looks like 12 additional pad bytes on the user/process stack are neede= d to get back to alignment. > > That would produce: > > Frame at: 0x...90 vs. 0x...10 > call by frame: 0x...b0 vs. 0x...10 > Arglist at: 0x...70 vs. 0x...d0 > Locals at: 0x...70 vs. 0x...d0 > Previous frame's sp: 0x...90 vs. 0x...10 > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > On 2016-Jan-31, at 10:47 PM, Mark Millard wrote: > > More evidence: By adding "break raise" and then using "info frame" to sho= w the alignment at that point I can show that the later signal delivery cha= nges the alignment on the user process stack compared to when raise was cal= led. (Later I show the same for thr_kill.) > >> Breakpoint 2, __raise (s=3D29) at /usr/src/lib/libc/gen/raise.c:50 >> warning: Source file is more recent than executable. >> 50 if (__sys_thr_self(&id) =3D=3D -1) >> (gdb) info frame >> Stack level 0, frame at 0xffffdc90: >> pc =3D 0x41904630 in __raise (/usr/src/lib/libc/gen/raise.c:50); saved p= c =3D 0x1800774 >> called by frame at 0xffffdcb0 >> source language c. >> Arglist at 0xffffdc70, args: s=3D29 >> Locals at 0xffffdc70, Previous frame's sp is 0xffffdc90 >> Saved registers: >> r29 at 0xffffdc84, r30 at 0xffffdc88, r31 at 0xffffdc8c, pc at 0xffffdc9= 4, lr at 0xffffdc94 >> (gdb) cont >> Continuing. >> >> Program received signal SIGINFO, Information request. >> >> Breakpoint 1, 0x018006d0 in handler () >> (gdb) info frame >> Stack level 0, frame at 0xffffd71c: >> pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 >> called by frame at 0xffffd71c >> Arglist at 0xffffd6dc, args: >> Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c >> Saved registers: >> r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 > > Note the difference (raise before delivery vs. handler via delivery): > > Frame at: 0x...90 vs. 0x...1c > call by frame: 0x...b0 vs. 0x...1c > Arglist at: 0x...70 vs. 0x...dc > Locals at: 0x...70 vs. 0x...dc > Previous frame's sp: 0x...90 vs. 0x...1c > > It looks like 4 additional pad bytes on the user/process stack are needed= to get back to alignment. > > [The span of addresses seems to be about: 0xffffdc90-0xffffd6dc=3D=3D0x5B= 4=3D=3D1460 (raise's "frame at" minus handler's "Locals at").] > > > If I look at the frame for "break thr_kill" it also still shows an aligne= d user/process stack before the delivery: > >> Breakpoint 3, 0x419046a0 in thr_kill () from /lib/libc.so.7 >> (gdb) info frame >> Stack level 0, frame at 0xffffdc70: >> pc =3D 0x419046a0 in thr_kill; saved pc =3D 0x41904650 >> called by frame at 0xffffdc90 >> Arglist at 0xffffdc70, args: >> Locals at 0xffffdc70, Previous frame's sp is 0xffffdc70 > > (The relevant addresses are the same as raise showed.) > > > Reminder of the source program structure that uses the potentially frame/= stack alignment sensitive libc/stdio library code: > >> # more sig_snprintf_use_test.c >> #include // for signal, SIGINFO, SIG_ERR, raise. >> #include // for snprintf >> >> void handler(int sig) >> { >> char buf[32]; >> snprintf(buf, sizeof buf, "%d", sig); // FreeBSD's world does such >> // things in some of its handlers= . >> } >> >> int main(void) >> { >> handler(0); // handler gets aligned stack frame for this; snprintf work= s here. >> if (signal(SIGINFO, handler) !=3D SIG_ERR) raise(SIGINFO); >> // raise gets aligned stack frame; >> // handler gets misaligned stack frame; >> // snprintf/__vfrpintf/io_flush/__sfvwrite/= memcpy: >> // when built by clang 3.8.0 are sensitive = to >> // the misalignment. >> return 0; >> } > > > > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > On 2016-Jan-31, at 9:12 PM, Mark Millard wrote: > > A summary of the later finding details for what I've done so far: > > It is system library code (__vfprintf and its inline io_flush call to __s= fvwrite) that may produce and use a potentially bad &iop->uio address, depe= nding the mix of how the calculation works and the stack/frame alignment pr= esent in signal delivery. The gcc 4.2.1 vs. clang 3.8.0 program status make= s no difference to if it ends up with a segmentation fault or not. > > When __vfprintf and its inline io_flush call to __sfvwrite is compiled by= gcc 4.2.1 --which always uses addition for offsets, voiding alignment assu= mptions-- no variant of the program gets a segmentation fault. gcc 4.2.1 do= es not create the dependency on the alignment that clang 3.8.0 does. Yet th= e misalignment is present. (See the details.) > > When clang3.8.0 compiles __vfprintf and its inline io_flush call to __sfv= write --which uses masking for the offset in calculating &iop->uio, making = alignment assumptions-- every variant of the program gets a segmentation fa= ult. (The misalignment is still present.) > > > > The details for the misalignment evidence follow. > > For (C) "on a pure gcc 4.2.1 buildworld/buildkernel system". . . > > C0) For gcc421-a.out gets signal delivery to its handler: "info frame" in= this (C) context: > > This *has* a misaligned signal delivery stack but there is no segmentatio= n fault. > >> Program received signal SIGINFO, Information request. >> >> Breakpoint 1, 0x018006e0 in handler () >> (gdb) bt >> #0 0x018006e0 in handler () >> #1 >> #2 0x00000000 in ?? () >> (gdb) info frame >> Stack level 0, frame at 0xffffd73c: >> pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 >> called by frame at 0xffffd73c >> Arglist at 0xffffd6fc, args: >> Locals at 0xffffd6fc, Previous frame's sp is 0xffffd73c >> Saved registers: >> r31 at 0xffffd738, pc at 0xffffd740, lr at 0xffffd740 > > > So misaligned (multiple of 4 but of no higher power of 2) for "frame at",= "called by frame at" (which is listed as the same as "frame at"), "Arglist= ", "Locals", and "Previous frame's sp" (which is listed as the same as "fra= me at"). > > In this case I also list __vfprintf's misalignment evidence for reference= : > (break __vfprintf used.) > >> (gdb) info frame >> Stack level 0, frame at 0xffffd57c: >> pc =3D 0x41930af8 in __vfprintf (/usr/src/lib/libc/stdio/vfprintf.c:452)= ; saved pc =3D 0x41992e18 >> called by frame at 0xffffd6fc >> source language c. >> Arglist at 0xffffd29c, args: fp=3D0xffffd5dc, locale=3D0x419c41e0 <__xlo= cale_global_locale>, fmt0=3D0x1800a1c "%d", ap=3D0xffffd6cc >> Locals at 0xffffd29c, Previous frame's sp is 0xffffd57c >> Saved registers: >> r30 at 0xffffd574, r31 at 0xffffd578, pc at 0xffffd580, lr at 0xffffd580 > > > So misaligned (multiple of 4 but of no higher power of 2) for "frame at",= "called by frame at", "Arglist", "Locals", and "Previous frame's sp" (whic= h is listed as the same as "frame at"). > > Just to have one for reference, here is the "info frame" for the direct h= andler call --which gets a properly aligned frame/stack: > >> (gdb) info frame >> Stack level 0, frame at 0xffffdcc0: >> pc =3D 0x18006e0 in handler; saved pc =3D 0x1800734 >> called by frame at 0xffffdcd0 >> Arglist at 0xffffdc80, args: >> Locals at 0xffffdc80, Previous frame's sp is 0xffffdcc0 >> Saved registers: >> r31 at 0xffffdcbc, pc at 0xffffdcc4, lr at 0xffffdcc4 > > Only the signal delivery is creating non-aligned stack frames. > > > C1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (C) context: > > This *has* a misaligned signal delivery stack but there is no segmentatio= n fault. > >> (gdb) info frame >> Stack level 0, frame at 0xffffd70c: >> pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 >> called by frame at 0xffffd70c >> Arglist at 0xffffd6cc, args: >> Locals at 0xffffd6cc, Previous frame's sp is 0xffffd70c >> Saved registers: >> r31 at 0xffffd708, pc at 0xffffd710, lr at 0xffffd710 > > So misaligned (multiple of 4 but of no higher power of 2) for "frame at",= "called by frame at", "Arglist", "Locals", and "Previous frame's sp" (whic= h is listed as the same as "frame at"). > > > > For (B) "on a clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix". . . > > B0) For gcc421-a.out gets signal delivery to its handler: "info frame" in= this (B) context: > > This *has* a misaligned signal delivery stack and there *is* a segmentati= on fault. > >> Program received signal SIGINFO, Information request. >> >> Breakpoint 1, 0x018006e0 in handler () >> (gdb) bt >> #0 0x018006e0 in handler () >> #1 >> #2 0x00000000 in ?? () >> (gdb) info frame >> Stack level 0, frame at 0xffffd74c: >> pc =3D 0x18006e0 in handler; saved pc =3D 0xffffe008 >> called by frame at 0xffffd74c >> Arglist at 0xffffd70c, args: >> Locals at 0xffffd70c, Previous frame's sp is 0xffffd74c >> Saved registers: >> r31 at 0xffffd748, pc at 0xffffd750, lr at 0xffffd750 >> (gdb) cont >> Continuing. >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x419a89c8 in memcpy (dst0=3D0xffffd714, src0=3D, length= =3D) at /usr/src/lib/libc/string/bcopy.c:124 >> warning: Source file is more recent than executable. >> 124 TLOOP1(*--dst =3D *--src); > > > > B1) For clang380-a.out gets signal delivery to its handler: "info frame" = in this (B) context: > (i.e., what I originally reported on and submitted a Bug report for) > > This *has* a misaligned signal delivery stack and there *is* a segmentati= on fault. > >> Program received signal SIGINFO, Information request. >> >> Breakpoint 1, 0x018006d0 in handler () >> (gdb) info frame >> Stack level 0, frame at 0xffffd71c: >> pc =3D 0x18006d0 in handler; saved pc =3D 0xffffe008 >> called by frame at 0xffffd71c >> Arglist at 0xffffd6dc, args: >> Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c >> Saved registers: >> r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 >> (gdb) cont >> Continuing. >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x419a89c8 in memcpy (dst0=3D0xffffd6f4, src0=3D, length= =3D) at /usr/src/lib/libc/string/bcopy.c:124 >> warning: Source file is more recent than executable. >> 124 TLOOP1(*--dst =3D *--src); > > So misaligned (multiple of 4 but of no higher power of 2) for "frame at",= "called by frame at" (which is listed as the same as "frame at"), "Arglist= ", "Locals", and "Previous frame's sp" (which is listed as the same as "fra= me at"). > > > > More context notes. . . > > The "pure gcc 4.2.1 buildworld/buildkernel system" has: > > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r294960M: Wed Jan 2= 7 18:25:04 PST 2016 root@FBSDG4C0:/usr/obj/gcc421/powerpc.powerpc/usr/s= rc/sys/GENERICvtsc-NODEBUG powerpc 1100097 1100097 > > > The "clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix" has: > > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r294962M: Fri Jan 2= 9 18:28:17 PST 2016 markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.pow= erpc/usr/src/sys/GENERICvtsc-NODEBUG powerpc 1100097 1100097 > > (Same PowerMac, different SSD.) > > > [I have renamed a.out's to indicate compiler context as I've gone along.] > [I copied each a.out to the other SSD for use after compiling/linking.] > [I'm not generally showing the "direct call" properly aligned "info frame= " texts.] > [handle SIGINFO nostop print pass; break handler used in gdb 7.10_5.] > [For gcc 4.2.1 I used: gcc -std=3Dc99 -Wall sig_snprintf_use_test.c .] > [For clang 3.8.0 I used: clang -std=3Dc11 -Wall -Wpedantic sig_snprintf_u= se_test.c .] > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > On 2016-Jan-31, at 6:32 PM, Mark Millard wrote: > >> [I've never noticed gcc 4.2.1 generating code that was based on presumin= g the alignment was present. For example: it always seems to use addition t= o deal with address offsets, never masking. So I'd not expect to see segmen= tation faults for that context even when the stack is aligned modulo only 4= . Separately checking the alignment is appropriate for me to do.] >> >> A) The reported context: >> >> The kernel context here is a gcc 4.2.1 based buildkernel then installker= nel. >> The world context here is a clang 3.8.0 based buildworld then installwor= ld. >> The program context here is a clang 3.8.0 based: >> >>> # clang -std=3Dc11 -Wall -Wpedantic sig_snprintf_use_test.c >>> # /usr/local/bin/gdb a.out >> >> >> Using "break handler" in gdb (7.10_5) and using "info frame" when it sto= ps for the "raise" shows the misalignment of the frame that the handler was= given ny the signal delivery. >> >> By contrast the earlier direct call of the handler gets a "info frame" r= esult that shows the expected sort of alignment. >> >> I find no evidence of frame/stack misalignment via gdb except for the on= e that is created by the signal delivery. >> >> >> B) I'll look at trying one or more of gcc 4.2.1, gcc49, gcc5 for the pro= gram context, still based on a clang 3.8.0 buildworld and gcc 4.2.1 buildke= rnel based on projects/clang380-import (-r294962). >> >> C) I will look at trying the same program builds on a pure gcc 4.2.1 bui= ldworld/buildkernel context. (Likely 11.0-CURRENT -r294960.) >> >> >> I'll send more results when I have them. >> >> > > > > > =3D=3D=3D > Mark Millard > markmi at dsl-only.net > > On 2016-Jan-31, at 5:50 PM, Justin Hibbits wrot= e: > > Does this occur with gcc-built world and/or kernel? You could put some p= rintf()s in sendsig(), and there are KTR tracepoints already present. The = code assumes a fully aligned user stack, which should be correct, but may n= ot be. > > - Justin > On Jan 31, 2016, at 6:41 PM, Mark Millard wrote: > >> I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import stack = alignment problem for TARGET_ARCH=3Dpowerpc signal delivery. >> >> =3D=3D=3D >> Mark Millard >> markmi at dsl-only.net >> >> On 2016-Jan-31, at 6:08 AM, Roman Divacky wrote: >> >> Fwiw, LLVM expect 16B aligned stack on PowerPC. >> >> On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: >>> 3 quick FreeBSD for powerpc (32-bit) questions: >>> >>> >>> A) For PowerPC (32-bit) what is the stack alignment requirement by the = ABI(s) that FreeBSD targets? >>> >>> B) Are signal handlers supposed to be given that alignment? >>> >>> >>> I ask because signal handlers are at times begin given just 4-byte alig= nment but clang 3.8.0 powerpc's code generation can depend on the alignment= being more than 4. >>> >>> clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 r= elative to what would need to be an aligned address with alignment 8 or mor= e instead of adding 0x4 to a more arbitrary address. >>> >>> So far I've only seen less than 8 byte stack alignment via signal handl= er activity. >>> >>> >>> C) Which should be blamed for problems here: clang's code generation, F= reeBSD's stack alignment handling for signals, or both? >>> >>> =3D=3D=3D >>> Mark Millard >>> markmi at dsl-only.net >>> >>> _______________________________________________ >>> freebsd-toolchain@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd= .org" >> > > > > > > > From owner-freebsd-ppc@freebsd.org Tue Feb 2 16:13:31 2016 Return-Path: Delivered-To: freebsd-ppc@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 0A9A2A98413; Tue, 2 Feb 2016 16:13:31 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7E7A617D3; Tue, 2 Feb 2016 16:13:30 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u12GDHnb081391 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 2 Feb 2016 18:13:18 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u12GDHnb081391 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u12GDHBr081390; Tue, 2 Feb 2016 18:13:17 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Tue, 2 Feb 2016 18:13:17 +0200 From: Konstantin Belousov To: Justin Hibbits Cc: Mark Millard , FreeBSD Toolchain , Roman Divacky , FreeBSD PowerPC ML Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers [the change that caused misaligned] Message-ID: <20160202161317.GB91220@kib.kiev.ua> References: <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> <1CCB483E-882A-4068-AF5B-EF43DAF0BA79@dsl-only.net> <261D8A47-3B8A-4DE6-9D2C-F536C9143E84@dsl-only.net> <8D38E67E-B798-4EFD-951F-DADFDBAEDD8A@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 16:13:31 -0000 On Tue, Feb 02, 2016 at 10:05:16AM -0600, Justin Hibbits wrote: > Good catch! I'll commit the change tonight. I looked once at the powerpc sigsend(), and I think that it has an issue. The usfp is calculated by taking the stack pointer at the time of signal delivery and substracting the sigframe size. This means that a transient misalignment during some code (e.g. leaf function) is transferred to the signal handler execution. Other arches explicitely realign stack pointer for the signal frame before the frame is formed. I am not sure if the problem reported in the thread is caused by this or not, but forced realignment in sendsig() is required for ABI compliance. > > - Justin > > On Tue, Feb 2, 2016 at 3:48 AM, Mark Millard wrote: > > I tried the change to -32 and 32 (from -20 and 20) on/for the powerpc (32-bit) PowerMac that I use and the results were: > > > > A) "info frame" in gdb shows signal handlers are now started with 16-byte aligned stack frames. (Applies to gcc 4.2.1 based contexts too, not just to the clang 3.8.0 ones with the __vfprintf-tied segmentation faults during signals.) > > > > and. . . > > > > B) The "clang 3.8.0 compiled __vfprintf" segmentation faults in libc/stdio library code during signal handlers that use such code no longer happen because the alignment matches the code requirements. > > > > I've added this information to Bug 206810. > > > > > > (Note: There are a couple of segmentation fault contexts that I've never tied down to any specific property: no discovered evidence of signal handler involvement or of __vfprintf involvement, for example. These are still a problem. But where I had tied the faults to signal handlers using __vfprintf now instead work fine in my experimental clang 3.8.0 based builds.) > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On 2016-Feb-1, at 12:11 AM, Mark Millard wrote: > > > > The -16/16 code below produced correct alignment but too little space. > > > > The -20/20 code below produces enough space but misalignment. > > > > To maintain 16-byte alignment while increasing the space would have required going from -16/16 to -32/32. At least that is how I understand this code. > > > > > >> Index: sys/powerpc/powerpc/sigcode32.S > >> =================================================================== > >> --- sys/powerpc/powerpc/sigcode32.S (.../head/sys/powerpc/powerpc/sigcode32.S) (revision 209975) > >> +++ sys/powerpc/powerpc/sigcode32.S (.../projects/clang380-import/sys/powerpc/powerpc/sigcode32.S) (working copy) > >> @@ -45,9 +45,9 @@ > >> */ > >> .globl CNAME(sigcode32),CNAME(szsigcode32) > >> CNAME(sigcode32): > >> - addi 1,1,-16 /* reserved space for callee */ > >> + addi 1,1,-20 /* reserved space for callee */ > >> blrl > >> - addi 3,1,16+SF_UC /* restore sp, and get &frame->sf_uc */ > >> + addi 3,1,20+SF_UC /* restore sp, and get &frame->sf_uc */ > >> li 0,SYS_sigreturn > >> sc /* sigreturn(scp) */ > >> li 0,SYS_exit > > > > > > > > The "working copy" is -r266778 from 2014-May-27. > > > > -r209975 is from 2010-Jul-13. > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On 2016-Jan-31, at 10:58 PM, Mark Millard wrote: > > > > Just a correction to a sentence that I wrote. I had written: > > > >> Frame at: 0x...90 vs. 0x...1c > >> call by frame: 0x...b0 vs. 0x...1c > >> Arglist at: 0x...70 vs. 0x...dc > >> Locals at: 0x...70 vs. 0x...dc > >> Previous frame's sp: 0x...90 vs. 0x...1c > >> > >> It looks like 4 additional pad bytes on the user/process stack are needed to get back to alignment. > > > > Of course the figures on the right need to get smaller, not larger: The stack grows towards smaller addresses. So to get to 0x...0 on the right I should have said: > > > > It looks like 12 additional pad bytes on the user/process stack are needed to get back to alignment. > > > > That would produce: > > > > Frame at: 0x...90 vs. 0x...10 > > call by frame: 0x...b0 vs. 0x...10 > > Arglist at: 0x...70 vs. 0x...d0 > > Locals at: 0x...70 vs. 0x...d0 > > Previous frame's sp: 0x...90 vs. 0x...10 > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On 2016-Jan-31, at 10:47 PM, Mark Millard wrote: > > > > More evidence: By adding "break raise" and then using "info frame" to show the alignment at that point I can show that the later signal delivery changes the alignment on the user process stack compared to when raise was called. (Later I show the same for thr_kill.) > > > >> Breakpoint 2, __raise (s=29) at /usr/src/lib/libc/gen/raise.c:50 > >> warning: Source file is more recent than executable. > >> 50 if (__sys_thr_self(&id) == -1) > >> (gdb) info frame > >> Stack level 0, frame at 0xffffdc90: > >> pc = 0x41904630 in __raise (/usr/src/lib/libc/gen/raise.c:50); saved pc = 0x1800774 > >> called by frame at 0xffffdcb0 > >> source language c. > >> Arglist at 0xffffdc70, args: s=29 > >> Locals at 0xffffdc70, Previous frame's sp is 0xffffdc90 > >> Saved registers: > >> r29 at 0xffffdc84, r30 at 0xffffdc88, r31 at 0xffffdc8c, pc at 0xffffdc94, lr at 0xffffdc94 > >> (gdb) cont > >> Continuing. > >> > >> Program received signal SIGINFO, Information request. > >> > >> Breakpoint 1, 0x018006d0 in handler () > >> (gdb) info frame > >> Stack level 0, frame at 0xffffd71c: > >> pc = 0x18006d0 in handler; saved pc = 0xffffe008 > >> called by frame at 0xffffd71c > >> Arglist at 0xffffd6dc, args: > >> Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > >> Saved registers: > >> r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 > > > > Note the difference (raise before delivery vs. handler via delivery): > > > > Frame at: 0x...90 vs. 0x...1c > > call by frame: 0x...b0 vs. 0x...1c > > Arglist at: 0x...70 vs. 0x...dc > > Locals at: 0x...70 vs. 0x...dc > > Previous frame's sp: 0x...90 vs. 0x...1c > > > > It looks like 4 additional pad bytes on the user/process stack are needed to get back to alignment. > > > > [The span of addresses seems to be about: 0xffffdc90-0xffffd6dc==0x5B4==1460 (raise's "frame at" minus handler's "Locals at").] > > > > > > If I look at the frame for "break thr_kill" it also still shows an aligned user/process stack before the delivery: > > > >> Breakpoint 3, 0x419046a0 in thr_kill () from /lib/libc.so.7 > >> (gdb) info frame > >> Stack level 0, frame at 0xffffdc70: > >> pc = 0x419046a0 in thr_kill; saved pc = 0x41904650 > >> called by frame at 0xffffdc90 > >> Arglist at 0xffffdc70, args: > >> Locals at 0xffffdc70, Previous frame's sp is 0xffffdc70 > > > > (The relevant addresses are the same as raise showed.) > > > > > > Reminder of the source program structure that uses the potentially frame/stack alignment sensitive libc/stdio library code: > > > >> # more sig_snprintf_use_test.c > >> #include // for signal, SIGINFO, SIG_ERR, raise. > >> #include // for snprintf > >> > >> void handler(int sig) > >> { > >> char buf[32]; > >> snprintf(buf, sizeof buf, "%d", sig); // FreeBSD's world does such > >> // things in some of its handlers. > >> } > >> > >> int main(void) > >> { > >> handler(0); // handler gets aligned stack frame for this; snprintf works here. > >> if (signal(SIGINFO, handler) != SIG_ERR) raise(SIGINFO); > >> // raise gets aligned stack frame; > >> // handler gets misaligned stack frame; > >> // snprintf/__vfrpintf/io_flush/__sfvwrite/memcpy: > >> // when built by clang 3.8.0 are sensitive to > >> // the misalignment. > >> return 0; > >> } > > > > > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On 2016-Jan-31, at 9:12 PM, Mark Millard wrote: > > > > A summary of the later finding details for what I've done so far: > > > > It is system library code (__vfprintf and its inline io_flush call to __sfvwrite) that may produce and use a potentially bad &iop->uio address, depending the mix of how the calculation works and the stack/frame alignment present in signal delivery. The gcc 4.2.1 vs. clang 3.8.0 program status makes no difference to if it ends up with a segmentation fault or not. > > > > When __vfprintf and its inline io_flush call to __sfvwrite is compiled by gcc 4.2.1 --which always uses addition for offsets, voiding alignment assumptions-- no variant of the program gets a segmentation fault. gcc 4.2.1 does not create the dependency on the alignment that clang 3.8.0 does. Yet the misalignment is present. (See the details.) > > > > When clang3.8.0 compiles __vfprintf and its inline io_flush call to __sfvwrite --which uses masking for the offset in calculating &iop->uio, making alignment assumptions-- every variant of the program gets a segmentation fault. (The misalignment is still present.) > > > > > > > > The details for the misalignment evidence follow. > > > > For (C) "on a pure gcc 4.2.1 buildworld/buildkernel system". . . > > > > C0) For gcc421-a.out gets signal delivery to its handler: "info frame" in this (C) context: > > > > This *has* a misaligned signal delivery stack but there is no segmentation fault. > > > >> Program received signal SIGINFO, Information request. > >> > >> Breakpoint 1, 0x018006e0 in handler () > >> (gdb) bt > >> #0 0x018006e0 in handler () > >> #1 > >> #2 0x00000000 in ?? () > >> (gdb) info frame > >> Stack level 0, frame at 0xffffd73c: > >> pc = 0x18006e0 in handler; saved pc = 0xffffe008 > >> called by frame at 0xffffd73c > >> Arglist at 0xffffd6fc, args: > >> Locals at 0xffffd6fc, Previous frame's sp is 0xffffd73c > >> Saved registers: > >> r31 at 0xffffd738, pc at 0xffffd740, lr at 0xffffd740 > > > > > > So misaligned (multiple of 4 but of no higher power of 2) for "frame at", "called by frame at" (which is listed as the same as "frame at"), "Arglist", "Locals", and "Previous frame's sp" (which is listed as the same as "frame at"). > > > > In this case I also list __vfprintf's misalignment evidence for reference: > > (break __vfprintf used.) > > > >> (gdb) info frame > >> Stack level 0, frame at 0xffffd57c: > >> pc = 0x41930af8 in __vfprintf (/usr/src/lib/libc/stdio/vfprintf.c:452); saved pc = 0x41992e18 > >> called by frame at 0xffffd6fc > >> source language c. > >> Arglist at 0xffffd29c, args: fp=0xffffd5dc, locale=0x419c41e0 <__xlocale_global_locale>, fmt0=0x1800a1c "%d", ap=0xffffd6cc > >> Locals at 0xffffd29c, Previous frame's sp is 0xffffd57c > >> Saved registers: > >> r30 at 0xffffd574, r31 at 0xffffd578, pc at 0xffffd580, lr at 0xffffd580 > > > > > > So misaligned (multiple of 4 but of no higher power of 2) for "frame at", "called by frame at", "Arglist", "Locals", and "Previous frame's sp" (which is listed as the same as "frame at"). > > > > Just to have one for reference, here is the "info frame" for the direct handler call --which gets a properly aligned frame/stack: > > > >> (gdb) info frame > >> Stack level 0, frame at 0xffffdcc0: > >> pc = 0x18006e0 in handler; saved pc = 0x1800734 > >> called by frame at 0xffffdcd0 > >> Arglist at 0xffffdc80, args: > >> Locals at 0xffffdc80, Previous frame's sp is 0xffffdcc0 > >> Saved registers: > >> r31 at 0xffffdcbc, pc at 0xffffdcc4, lr at 0xffffdcc4 > > > > Only the signal delivery is creating non-aligned stack frames. > > > > > > C1) For clang380-a.out gets signal delivery to its handler: "info frame" in this (C) context: > > > > This *has* a misaligned signal delivery stack but there is no segmentation fault. > > > >> (gdb) info frame > >> Stack level 0, frame at 0xffffd70c: > >> pc = 0x18006d0 in handler; saved pc = 0xffffe008 > >> called by frame at 0xffffd70c > >> Arglist at 0xffffd6cc, args: > >> Locals at 0xffffd6cc, Previous frame's sp is 0xffffd70c > >> Saved registers: > >> r31 at 0xffffd708, pc at 0xffffd710, lr at 0xffffd710 > > > > So misaligned (multiple of 4 but of no higher power of 2) for "frame at", "called by frame at", "Arglist", "Locals", and "Previous frame's sp" (which is listed as the same as "frame at"). > > > > > > > > For (B) "on a clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix". . . > > > > B0) For gcc421-a.out gets signal delivery to its handler: "info frame" in this (B) context: > > > > This *has* a misaligned signal delivery stack and there *is* a segmentation fault. > > > >> Program received signal SIGINFO, Information request. > >> > >> Breakpoint 1, 0x018006e0 in handler () > >> (gdb) bt > >> #0 0x018006e0 in handler () > >> #1 > >> #2 0x00000000 in ?? () > >> (gdb) info frame > >> Stack level 0, frame at 0xffffd74c: > >> pc = 0x18006e0 in handler; saved pc = 0xffffe008 > >> called by frame at 0xffffd74c > >> Arglist at 0xffffd70c, args: > >> Locals at 0xffffd70c, Previous frame's sp is 0xffffd74c > >> Saved registers: > >> r31 at 0xffffd748, pc at 0xffffd750, lr at 0xffffd750 > >> (gdb) cont > >> Continuing. > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> 0x419a89c8 in memcpy (dst0=0xffffd714, src0=, length=) at /usr/src/lib/libc/string/bcopy.c:124 > >> warning: Source file is more recent than executable. > >> 124 TLOOP1(*--dst = *--src); > > > > > > > > B1) For clang380-a.out gets signal delivery to its handler: "info frame" in this (B) context: > > (i.e., what I originally reported on and submitted a Bug report for) > > > > This *has* a misaligned signal delivery stack and there *is* a segmentation fault. > > > >> Program received signal SIGINFO, Information request. > >> > >> Breakpoint 1, 0x018006d0 in handler () > >> (gdb) info frame > >> Stack level 0, frame at 0xffffd71c: > >> pc = 0x18006d0 in handler; saved pc = 0xffffe008 > >> called by frame at 0xffffd71c > >> Arglist at 0xffffd6dc, args: > >> Locals at 0xffffd6dc, Previous frame's sp is 0xffffd71c > >> Saved registers: > >> r31 at 0xffffd718, pc at 0xffffd720, lr at 0xffffd720 > >> (gdb) cont > >> Continuing. > >> > >> Program received signal SIGSEGV, Segmentation fault. > >> 0x419a89c8 in memcpy (dst0=0xffffd6f4, src0=, length=) at /usr/src/lib/libc/string/bcopy.c:124 > >> warning: Source file is more recent than executable. > >> 124 TLOOP1(*--dst = *--src); > > > > So misaligned (multiple of 4 but of no higher power of 2) for "frame at", "called by frame at" (which is listed as the same as "frame at"), "Arglist", "Locals", and "Previous frame's sp" (which is listed as the same as "frame at"). > > > > > > > > More context notes. . . > > > > The "pure gcc 4.2.1 buildworld/buildkernel system" has: > > > > # freebsd-version -ku; uname -aKU > > 11.0-CURRENT > > 11.0-CURRENT > > FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #5 r294960M: Wed Jan 27 18:25:04 PST 2016 root@FBSDG4C0:/usr/obj/gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODEBUG powerpc 1100097 1100097 > > > > > > The "clang 3.8.0 buildworld and gcc 4.2.1 buildkernel mix" has: > > > > # freebsd-version -ku; uname -aKU > > 11.0-CURRENT > > 11.0-CURRENT > > FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r294962M: Fri Jan 29 18:28:17 PST 2016 markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.powerpc/usr/src/sys/GENERICvtsc-NODEBUG powerpc 1100097 1100097 > > > > (Same PowerMac, different SSD.) > > > > > > [I have renamed a.out's to indicate compiler context as I've gone along.] > > [I copied each a.out to the other SSD for use after compiling/linking.] > > [I'm not generally showing the "direct call" properly aligned "info frame" texts.] > > [handle SIGINFO nostop print pass; break handler used in gdb 7.10_5.] > > [For gcc 4.2.1 I used: gcc -std=c99 -Wall sig_snprintf_use_test.c .] > > [For clang 3.8.0 I used: clang -std=c11 -Wall -Wpedantic sig_snprintf_use_test.c .] > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On 2016-Jan-31, at 6:32 PM, Mark Millard wrote: > > > >> [I've never noticed gcc 4.2.1 generating code that was based on presuming the alignment was present. For example: it always seems to use addition to deal with address offsets, never masking. So I'd not expect to see segmentation faults for that context even when the stack is aligned modulo only 4. Separately checking the alignment is appropriate for me to do.] > >> > >> A) The reported context: > >> > >> The kernel context here is a gcc 4.2.1 based buildkernel then installkernel. > >> The world context here is a clang 3.8.0 based buildworld then installworld. > >> The program context here is a clang 3.8.0 based: > >> > >>> # clang -std=c11 -Wall -Wpedantic sig_snprintf_use_test.c > >>> # /usr/local/bin/gdb a.out > >> > >> > >> Using "break handler" in gdb (7.10_5) and using "info frame" when it stops for the "raise" shows the misalignment of the frame that the handler was given ny the signal delivery. > >> > >> By contrast the earlier direct call of the handler gets a "info frame" result that shows the expected sort of alignment. > >> > >> I find no evidence of frame/stack misalignment via gdb except for the one that is created by the signal delivery. > >> > >> > >> B) I'll look at trying one or more of gcc 4.2.1, gcc49, gcc5 for the program context, still based on a clang 3.8.0 buildworld and gcc 4.2.1 buildkernel based on projects/clang380-import (-r294962). > >> > >> C) I will look at trying the same program builds on a pure gcc 4.2.1 buildworld/buildkernel context. (Likely 11.0-CURRENT -r294960.) > >> > >> > >> I'll send more results when I have them. > >> > >> > > > > > > > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On 2016-Jan-31, at 5:50 PM, Justin Hibbits wrote: > > > > Does this occur with gcc-built world and/or kernel? You could put some printf()s in sendsig(), and there are KTR tracepoints already present. The code assumes a fully aligned user stack, which should be correct, but may not be. > > > > - Justin > > On Jan 31, 2016, at 6:41 PM, Mark Millard wrote: > > > >> I have submitted Bug 206810 for this 11.0-CURRENT/clang380-import stack alignment problem for TARGET_ARCH=powerpc signal delivery. > >> > >> === > >> Mark Millard > >> markmi at dsl-only.net > >> > >> On 2016-Jan-31, at 6:08 AM, Roman Divacky wrote: > >> > >> Fwiw, LLVM expect 16B aligned stack on PowerPC. > >> > >> On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote: > >>> 3 quick FreeBSD for powerpc (32-bit) questions: > >>> > >>> > >>> A) For PowerPC (32-bit) what is the stack alignment requirement by the ABI(s) that FreeBSD targets? > >>> > >>> B) Are signal handlers supposed to be given that alignment? > >>> > >>> > >>> I ask because signal handlers are at times begin given just 4-byte alignment but clang 3.8.0 powerpc's code generation can depend on the alignment being more than 4. > >>> > >>> clang 3.8.0 can calculate addresses by, for example, masking in a 0x4 relative to what would need to be an aligned address with alignment 8 or more instead of adding 0x4 to a more arbitrary address. > >>> > >>> So far I've only seen less than 8 byte stack alignment via signal handler activity. > >>> > >>> > >>> C) Which should be blamed for problems here: clang's code generation, FreeBSD's stack alignment handling for signals, or both? > >>> > >>> === > >>> Mark Millard > >>> markmi at dsl-only.net > >>> > >>> _______________________________________________ > >>> freebsd-toolchain@freebsd.org mailing list > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > >>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" > >> > > > > > > > > > > > > > > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Tue Feb 2 16:20:06 2016 Return-Path: Delivered-To: freebsd-ppc@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 98C42A98600; Tue, 2 Feb 2016 16:20:06 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 571FA197F; Tue, 2 Feb 2016 16:20:06 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ob0-x22d.google.com with SMTP id is5so153624317obc.0; Tue, 02 Feb 2016 08:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Xv/L/zIAtzIJC/2yac1TZZKr2wvXRC7IbnYrRbdGqFk=; b=auctRQ0hKiwTA3eSFa48P0Q040E8wBg20q/LZ/YA75zT5KWeeiiWs4zxwKfrC6tcqg xJ4ZS1Nnyo9+MBdeD2mSlYpDoTQPfUHb0exKlmDcvhvx0q3NZgWyP+kNY930ahlRGYNU +WPG+jB8Oa8/lRQU5BS8TCPUifQPgG32v+Lp062g1WZSkMdJ0ShZE6Y03YD/C3Xfd+L6 1PZD4ZrX3gbazaSY4SOw/Th6RJwCuQRo5mF2cxebFJfklqUFhfv7gVzl9Mu+EPXy+L6O FM739/tWQsWkDsU+hV1NGWqYc37aePvwJQ+djXDYsz21pRFpe/sUAx58QMA3sYfgTcXR /3XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xv/L/zIAtzIJC/2yac1TZZKr2wvXRC7IbnYrRbdGqFk=; b=VB4DbRDmM4kP69NH0Vw+vW/U7m3677wXXsyXMp4zBTT4LBplTqo6h1H2Qlg6o+pdbi lN+xN2ab4ulSI1ymWSLVG4hFGdi4uT59van2JNsuRp+pDwh1UbX81A2dGR28LYCaQ7Bu 6o60IhcKLazdvbEDZykEifcvXf3tGAueNhTQGimuDuAFqqMpFOeYZRrh5tatvVUCsq6L iPx0+kLOQLIJg/YjTdp26AJa5JXRntxDPRp9nr/W8wdEs2crqCPKZbrEwzKWySl/5qU8 Ll+I+iUzO4qiKuK7bkt8fXt7a12eOE9kH+WLqeLztI3gBcAwy+vfsQQ1LlLnQCyA4udc KKZw== X-Gm-Message-State: AG10YORgs7BEBqLN/BW1ovFymWdgl9sgyshonVHzCnJJlRgHUMHOavcZPj+lLwK1SbNOR+WqoG2Eq4mLSmDoxA== MIME-Version: 1.0 X-Received: by 10.182.70.70 with SMTP id k6mr23464550obu.74.1454430005559; Tue, 02 Feb 2016 08:20:05 -0800 (PST) Received: by 10.182.74.101 with HTTP; Tue, 2 Feb 2016 08:20:05 -0800 (PST) In-Reply-To: <20160202161317.GB91220@kib.kiev.ua> References: <20160131140807.GA83147@vlakno.cz> <0716BE3E-B7D1-4A10-B011-C1F0245296E7@dsl-only.net> <70A66DFD-557A-4D82-813C-05EED6EAB089@dsl-only.net> <1CCB483E-882A-4068-AF5B-EF43DAF0BA79@dsl-only.net> <261D8A47-3B8A-4DE6-9D2C-F536C9143E84@dsl-only.net> <8D38E67E-B798-4EFD-951F-DADFDBAEDD8A@dsl-only.net> <20160202161317.GB91220@kib.kiev.ua> Date: Tue, 2 Feb 2016 10:20:05 -0600 Message-ID: Subject: Re: 3 quick questions about stack alignment for powerpc (32-bit) signal handlers [the change that caused misaligned] From: Justin Hibbits To: Konstantin Belousov Cc: Mark Millard , FreeBSD Toolchain , Roman Divacky , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 16:20:06 -0000 On Tue, Feb 2, 2016 at 10:13 AM, Konstantin Belousov wrote: > On Tue, Feb 02, 2016 at 10:05:16AM -0600, Justin Hibbits wrote: >> Good catch! I'll commit the change tonight. > I looked once at the powerpc sigsend(), and I think that it has an > issue. The usfp is calculated by taking the stack pointer at the time > of signal delivery and substracting the sigframe size. This means that > a transient misalignment during some code (e.g. leaf function) is > transferred to the signal handler execution. > > Other arches explicitely realign stack pointer for the signal > frame before the frame is formed. > > I am not sure if the problem reported in the thread is caused by this > or not, but forced realignment in sendsig() is required for ABI compliance. Good point. Currently the assumption is that the stack will always be 16-byte aligned, which is required per ABI. Since there's no push/pop, only full frame creation/destruction, it hasn't bitten us yet, but it should be fixed. It's not the cause of this bug, though. This bug is caused after sendsig(), in the sigcode trampoline in user space. - Justin From owner-freebsd-ppc@freebsd.org Fri Feb 5 07:46:54 2016 Return-Path: Delivered-To: freebsd-ppc@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 433069D90DB for ; Fri, 5 Feb 2016 07:46:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0869819FA for ; Fri, 5 Feb 2016 07:46:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2334 invoked from network); 5 Feb 2016 07:46:50 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Feb 2016 07:46:50 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 05 Feb 2016 02:46:55 -0500 (EST) Received: (qmail 11224 invoked from network); 5 Feb 2016 07:46:54 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 5 Feb 2016 07:46:54 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B4CC31C42A3 for ; Thu, 4 Feb 2016 23:46:44 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: projects/clang380-import -r294962+ based powerpc (32-bit) buildworld -j 6: make gets SEGV, a partial smoking gun? Message-Id: Date: Thu, 4 Feb 2016 23:46:50 -0800 To: FreeBSD PowerPC ML Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 07:46:54 -0000 The problem: For a clang 3.8.0 based buildworld TARGET_ARCH=3Dpowerpc installation = attempting "make -j 6 buildworld" (run on 4 powerpc cores) eventually = gets a segmentation fault in a make instance. (More details later.) = "make buildworld" does not fault. I expect that the details that I describe below implies some form of = intermittency, such as a race condition. (This is with the content of sys/powerpc/powerpc/sigcode32.S -r295186 in = place so that signal delivery maintains the modulo 16 byte stack/frame = alignment status instead of changing the alignment.) (clang 3.8.0 targeting powerpc (32-bit) is known to be able to introduce = more stack alignment dependencies by sometimes "or-ing" in offset-bits = into some aligned-address lower bits instead of using addition. But I do = not know if that is involved here somehow.) What is always involved and what varies: In all cases the failure was r31 being used as a frame-pointer with the = value zero in r31 at the time of the address calculation, even when when = the dereference of the address was later. r1 still seemed to be a valid = stack pointer in all cases. In every case the faulting routine had called one or more routines = during its operation --and those had returned. There was an example or = two of a self-contained routine that was recursive that got the failure. In some cases prior calls in the faulting routine had non-zero r31 = values when they returned. (There was later r31 usage that did not = fault.) Overall the call chains varied widely for various example faults, = although some call context is more common as a failure point. Use of ktrace with "-di -t cs" and use of kdump for extracting for the = failing process shows the same 5 line sequence before every example = "PSIG SIGSEGV". What was before those 5 lines varied across the various = kdsump outputs. I used ktrace/kdump commands of the structure: ktrace -di -f /usr/obj/make.out -t cs -p ??? kdump -E -f /usr/obj/make.out -p ??? > = /var/tmp/make_ktrace_sigsegv_??.txt Example results (showing the 5 lines and PSIG SIGSEGV): (3 prior "sigreturn JUSTRETURN" among what is not shown) > 65158 make 0.205791 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED > 65158 make 0.205822 CALL write(0x3,0x189e914,0x1) > 65158 make 0.205847 RET write 1 > 65158 make 0.205869 CALL sigreturn(0xffffbb50) > 65158 make 0.205923 RET sigreturn JUSTRETURN > 65158 make 0.205962 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR (365 prior "sigreturn JUSTRETURN" among what is not shown) > 599 make 5.552305 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED > 599 make 5.552323 CALL write(0x3,0x189e914,0x1) > 599 make 5.552337 RET write 1 > 599 make 5.552347 CALL sigreturn(0xffffbb30) > 599 make 5.552358 RET sigreturn JUSTRETURN > 599 make 5.552381 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR (287 prior "sigreturn JUSTRETURN" among what is not shown) > 75728 make 4.141097 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED > 75728 make 4.141116 CALL write(0x3,0x189e914,0x1) > 75728 make 4.141154 RET write 1 > 75728 make 4.141349 CALL sigreturn(0xffffbaa0) > 75728 make 4.141366 RET sigreturn JUSTRETURN > 75728 make 4.141404 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR (273 prior "sigreturn JUSTRETURN" among what is not shown) > 12195 make 27.213277 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED > 12195 make 27.213322 CALL write(0x3,0x189e914,0x1) > 12195 make 27.213346 RET write 1 > 12195 make 27.213361 CALL sigreturn(0xffffb1e0) > 12195 make 27.213383 RET sigreturn JUSTRETURN > 12195 make 27.213418 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR (789 prior "sigreturn JUSTRETURN" among what is not shown) > 50545 make 80.255162 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED > 50545 make 80.255192 CALL write(0x3,0x189e914,0x1) > 50545 make 80.255219 RET write 1 > 50545 make 80.255241 CALL sigreturn(0xffffafa0) > 50545 make 80.255265 RET sigreturn JUSTRETURN > 50545 make 80.255317 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR The 5 line sequence is not sufficient for the problem to occur but = appears to be necessary: There were sometimes hundreds of prior "PSIG = SIGCHLD". . ."RET sigreturn JUSTRETURNS" sequences for which they were = not followed by "PSIG SIGSEGV". But every failure tested with ktrace has = the 5 lines as an immediate prefix in the list for the process. Which instance of make varied and where in make the fault happens = varied. The "-E" elapsed times above and those JUSTRETURN counts give a = solid clue to there being variability in when the fault happens. I'll use some script log file sizes for the buidlworld as another = indication of variability. I've sorted them: 2942664 3304207 3342660 3474585 3941983 so spanning from 2.9 MBytes to 3.9 MBytes. I've since gotten a few with = less and some with more. Note: A couple of times with ktrace being involved it failed at an = earlier stage than I've seen otherwise. It may be that ktrace being = involved makes the problem more likely/frequent. Context basics (quad core PowerMac running TARGET_ARCH=3Dpowerpc = (32-bit)): # freebsd-version -ku; uname -aKU 11.0-CURRENT 11.0-CURRENT FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r294962M: Mon Feb = 1 00:31:03 PST 2016 = markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.powerpc/usr/src/sys/GENERI= Cvtsc-NODEBUG powerpc 1100097 1100097 This is with the content of sys/powerpc/powerpc/sigcode32.S -r295186 in = place so that signal delivery maintains the modulo 16 byte stack/frame = alignment status instead of changing the alignment. buildkernel was via gcc 4.2.1 buildworld was via clang 3.8.0 I'm not sure that I'm going to get much farther in tracking down the = source of the race(?) that leads to the SEGV's. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Fri Feb 5 09:59:36 2016 Return-Path: Delivered-To: freebsd-ppc@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 C4BDBA7773F for ; Fri, 5 Feb 2016 09:59:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89E6512A9 for ; Fri, 5 Feb 2016 09:59:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 27243 invoked from network); 5 Feb 2016 09:59:34 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 5 Feb 2016 09:59:34 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 05 Feb 2016 04:59:37 -0500 (EST) Received: (qmail 16680 invoked from network); 5 Feb 2016 09:59:36 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 5 Feb 2016 09:59:36 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id BC9D51C43A8; Fri, 5 Feb 2016 01:59:32 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: powerpc (32-bit) clang 3.8.0 vs. gcc 4.2.1 routine preamble mismatches: contributions to SEGV's differences Date: Fri, 5 Feb 2016 01:59:32 -0800 Message-Id: <3D08EB58-7FEF-432E-8192-77F988A75621@dsl-only.net> Cc: Roman Divacky , Justin Hibbits , Konstantin Belousov , Nathan Whitehorn To: FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 09:59:36 -0000 Clang 3.8.0 produced code uses r31 as a frame pointer in contexts where = gcc 4.2.1 produced code does not (ever?). This leaves clang's produced = code being more dependent on r31 handling, such as when resuming after = signal delivery. The following is one of the routines in "make" where a clang 3.8.0 based = "make" sometimes gets a SEGV after resuming after a SIGCHLD delivery, = the SEGV being from having r31=3D0x0 in a Frame Pointer (r31) based = address calculation that is at some point dereferenced. (See = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-February/008002.html = .) But gcc 4.2.1 does not use r31 as a frame pointer in the Str_Match that = it produces and so does not see the problem. gcc 4.2.1's produced code = simply uses the stack pointer as needed. clang 3.8.0 based Str_Match preamble (from make): 0x181a4a8 : mflr r0 0x181a4ac : stw r31,-4(r1) # Clang's frame = pointer (r31)=20 # saved before stack = pointer changed. 0x181a4b0 : stw r0,4(r1) # lr saved before = stack pointer changed. 0x181a4b4 : stwu r1,-32(r1) # Stack pointer = finally saved and # changed. 0x181a4b8 : mr r31,r1 # r31 is the frame = pointer under clang. 0x181a4bc : stw r30,24(r31) gcc 4.2.1 based Str_Match preamble: 0x1819cb8 : mflr r0 0x1819cbc : stwu r1,-32(r1) # Stack pointer saved = and changed first. 0x1819cc0 : stw r31,28(r1) # r31 saved after = stack pointer changed. 0x1819cc4 : mr r31,r3 # gcc 4.2.1 does not = reserve # r31 for use as a = frame pointer. 0x1819cc8 : stw r30,24(r1) 0x1819ccc : stw r0,36(r1) # lr saved after = stack pointer changed. (Str_Match is a self contained routine, although it is recursive.) Looking at some other gcc 4.2.1 preamble examples. . . 0x1823b58 : cmpwi cr7,r6,0 0x1823b5c : stwu r1,-64(r1) # Stack pointer saved = and changed "first" 0x1823b60 : mflr r0 0x1823b64 : lis r9,396 0x1823b68 : stw r25,36(r1) 0x1823b6c : addi r25,r9,8944 0x1823b70 : stw r26,40(r1) 0x1823b74 : mr r26,r3 0x1823b78 : stw r27,44(r1) 0x1823b7c : mr r27,r4 0x1823b80 : stw r28,48(r1) 0x1823b84 : mr r28,r8 0x1823b88 : stw r29,52(r1) 0x1823b8c : mr r29,r5 0x1823b90 : stw r31,60(r1) 0x1823b94 : mr r31,r7 # Again r31 is not a = frame pointer 0x1823b98 : stw r0,68(r1) 0x1823b9c : lwz r0,0(r25) 0x1823ba0 : stw r0,28(r1) 0x1823ba4 : li r0,0 0x1823ba8 : stw r30,56(r1) 0x1823bac : beq- cr7,0x1823bbc 0x1819f30 : mflr r0 # Stack pointer saved = and changed first 0x1819f34 : stwu r1,-32(r1) 0x1819f38 : stw r28,16(r1) 0x1819f3c : mr r28,r5 0x1819f40 : stw r30,24(r1) 0x1819f44 : mr r30,r3 0x1819f48 : stw r31,28(r1) 0x1819f4c : mr r31,r4 # Again r31 is not a = frame pointer 0x1819f50 : stw r29,20(r1) 0x1819f54 : stw r0,36(r1) 0x1819f58 : lbz r29,0(r4) 0x181fcac : mflr r0 # Stack pointer saved = and changed first 0x181fcb0 : stwu r1,-48(r1) 0x181fcb4 : lis r9,396 0x181fcb8 : stw r27,28(r1) 0x181fcbc : mr r27,r4 0x181fcc0 : stw r0,52(r1) 0x181fcc4 : stw r28,32(r1) 0x181fcc8 : mr r28,r7 0x181fccc : lwz r0,-1344(r9) 0x181fcd0 : stw r29,36(r1) 0x181fcd4 : mr r29,r5 0x181fcd8 : andi. r9,r0,512 0x181fcdc : stw r30,40(r1) 0x181fce0 : stw r31,44(r1) 0x181fce4 : mr r30,r8 0x181fce8 : mr r31,r6 # Again r31 is not a = frame pointer 0x1801d58 : mflr r0 # Stack pointer saved = and changed first 0x1801d5c : stwu r1,-48(r1) 0x1801d60 : stw r28,32(r1) 0x1801d64 : stw r0,52(r1) 0x1801d68 : stw r30,40(r1) 0x1801d6c : mr r30,r4 0x1801d70 : lwz r28,4(r3) 0x1801d74 : lwz r4,0(r3) 0x1801d78 : stw r29,36(r1) 0x1801d7c : add r29,r30,r28 0x1801d80 : cmpw cr7,r29,r4 0x1801d84 : stw r27,28(r1) 0x1801d88 : stw r31,44(r1) 0x1801d8c : mr r27,r5 0x1801d90 : mr r31,r3 # Again r31 is not a = frame pointer And so it goes for every intermittent SEGV related example (clang 3.8.0 = buildworld based) that I've examined: the matching gcc 4.2.1 code would = not try to use the the r31 values that clang does use. Instead gcc 4.2.1 = assigns an independent value to r31 before using it. In effect gcc 4.2.1 and clang 3.8.0 are not following the exact-same = call standard. If clang 3.8.0's code generation is left as is then a = conversion to its call standard requirements will be required if clang = 3.8.0 is to be used for powerpc (32-bit). "Works when gcc 4.2.1 is used" is not a great guide to "appropriate for = use with clang 3.8.0", at least in this area for powerpc (32-bit). (These notes presume a context with sys/powerpc/powerpc/sigcode32.S = -r295186 in place so that signal delivery maintains the modulo 16 byte = stack/frame alignment status instead of changing the alignment. It = appears that, while necessary, this is not sufficient for a clang 3.8.0 = based buildworld to operate with signals reliably. See = https://lists.freebsd.org/pipermail/freebsd-ppc/2016-February/008002.html = .) =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Fri Feb 5 10:39:01 2016 Return-Path: Delivered-To: freebsd-ppc@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 B2F16A9C360 for ; Fri, 5 Feb 2016 10:39:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-2.reflexion.net [208.70.210.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77EA1B2E for ; Fri, 5 Feb 2016 10:39:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12526 invoked from network); 5 Feb 2016 10:39:00 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 5 Feb 2016 10:39:00 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 05 Feb 2016 05:39:07 -0500 (EST) Received: (qmail 15262 invoked from network); 5 Feb 2016 10:39:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 5 Feb 2016 10:39:06 -0000 X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id AFCA11C43AE for ; Fri, 5 Feb 2016 02:38:58 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: projects/clang380-import -r294962+ based powerpc (32-bit) buildworld -j 6: make gets SEGV, a partial smoking gun? From: Mark Millard In-Reply-To: Date: Fri, 5 Feb 2016 02:38:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 10:39:01 -0000 On 2016-Feb-4, at 11:46 PM, Mark Millard wrote: >=20 > The problem: >=20 > For a clang 3.8.0 based buildworld TARGET_ARCH=3Dpowerpc installation = attempting "make -j 6 buildworld" (run on 4 powerpc cores) eventually = gets a segmentation fault in a make instance. (More details later.) = "make buildworld" does not fault. >=20 > I expect that the details that I describe below implies some form of = intermittency, such as a race condition. >=20 > (This is with the content of sys/powerpc/powerpc/sigcode32.S -r295186 = in place so that signal delivery maintains the modulo 16 byte = stack/frame alignment status instead of changing the alignment.) >=20 > (clang 3.8.0 targeting powerpc (32-bit) is known to be able to = introduce more stack alignment dependencies by sometimes "or-ing" in = offset-bits into some aligned-address lower bits instead of using = addition. But I do not know if that is involved here somehow.) >=20 >=20 >=20 > What is always involved and what varies: >=20 > In all cases the failure was r31 being used as a frame-pointer with = the value zero in r31 at the time of the address calculation, even when = when the dereference of the address was later. r1 still seemed to be a = valid stack pointer in all cases. >=20 > In every case the faulting routine had called one or more routines = during its operation --and those had returned. There was an example or = two of a self-contained routine that was recursive that got the failure. >=20 > In some cases prior calls in the faulting routine had non-zero r31 = values when they returned. (There was later r31 usage that did not = fault.) >=20 > Overall the call chains varied widely for various example faults, = although some call context is more common as a failure point. >=20 > Use of ktrace with "-di -t cs" and use of kdump for extracting for the = failing process shows the same 5 line sequence before every example = "PSIG SIGSEGV". What was before those 5 lines varied across the various = kdsump outputs. >=20 > I used ktrace/kdump commands of the structure: >=20 > ktrace -di -f /usr/obj/make.out -t cs -p ??? > kdump -E -f /usr/obj/make.out -p ??? > = /var/tmp/make_ktrace_sigsegv_??.txt >=20 > Example results (showing the 5 lines and PSIG SIGSEGV): >=20 > (3 prior "sigreturn JUSTRETURN" among what is not shown) >> 65158 make 0.205791 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED >> 65158 make 0.205822 CALL write(0x3,0x189e914,0x1) >> 65158 make 0.205847 RET write 1 >> 65158 make 0.205869 CALL sigreturn(0xffffbb50) >> 65158 make 0.205923 RET sigreturn JUSTRETURN >> 65158 make 0.205962 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR >=20 > (365 prior "sigreturn JUSTRETURN" among what is not shown) >> 599 make 5.552305 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED >> 599 make 5.552323 CALL write(0x3,0x189e914,0x1) >> 599 make 5.552337 RET write 1 >> 599 make 5.552347 CALL sigreturn(0xffffbb30) >> 599 make 5.552358 RET sigreturn JUSTRETURN >> 599 make 5.552381 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR >=20 > (287 prior "sigreturn JUSTRETURN" among what is not shown) >> 75728 make 4.141097 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED >> 75728 make 4.141116 CALL write(0x3,0x189e914,0x1) >> 75728 make 4.141154 RET write 1 >> 75728 make 4.141349 CALL sigreturn(0xffffbaa0) >> 75728 make 4.141366 RET sigreturn JUSTRETURN >> 75728 make 4.141404 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR >=20 > (273 prior "sigreturn JUSTRETURN" among what is not shown) >> 12195 make 27.213277 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED >> 12195 make 27.213322 CALL write(0x3,0x189e914,0x1) >> 12195 make 27.213346 RET write 1 >> 12195 make 27.213361 CALL sigreturn(0xffffb1e0) >> 12195 make 27.213383 RET sigreturn JUSTRETURN >> 12195 make 27.213418 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR >=20 > (789 prior "sigreturn JUSTRETURN" among what is not shown) >> 50545 make 80.255162 PSIG SIGCHLD caught handler=3D0x180aae0 = mask=3D0x0 code=3DCLD_EXITED >> 50545 make 80.255192 CALL write(0x3,0x189e914,0x1) >> 50545 make 80.255219 RET write 1 >> 50545 make 80.255241 CALL sigreturn(0xffffafa0) >> 50545 make 80.255265 RET sigreturn JUSTRETURN >> 50545 make 80.255317 PSIG SIGSEGV SIG_DFL code=3DSEGV_MAPERR >=20 > The 5 line sequence is not sufficient for the problem to occur but = appears to be necessary: There were sometimes hundreds of prior "PSIG = SIGCHLD". . ."RET sigreturn JUSTRETURNS" sequences for which they were = not followed by "PSIG SIGSEGV". But every failure tested with ktrace has = the 5 lines as an immediate prefix in the list for the process. >=20 > Which instance of make varied and where in make the fault happens = varied. The "-E" elapsed times above and those JUSTRETURN counts give a = solid clue to there being variability in when the fault happens. >=20 > I'll use some script log file sizes for the buidlworld as another = indication of variability. I've sorted them: >=20 > 2942664 > 3304207 > 3342660 > 3474585 > 3941983 >=20 > so spanning from 2.9 MBytes to 3.9 MBytes. I've since gotten a few = with less and some with more. >=20 >=20 > Note: A couple of times with ktrace being involved it failed at an = earlier stage than I've seen otherwise. It may be that ktrace being = involved makes the problem more likely/frequent. >=20 >=20 >=20 > Context basics (quad core PowerMac running TARGET_ARCH=3Dpowerpc = (32-bit)): >=20 > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG4C1 11.0-CURRENT FreeBSD 11.0-CURRENT #2 r294962M: Mon = Feb 1 00:31:03 PST 2016 = markmi@FreeBSDx64:/usr/obj/clang_gcc421/powerpc.powerpc/usr/src/sys/GENERI= Cvtsc-NODEBUG powerpc 1100097 1100097 >=20 > This is with the content of sys/powerpc/powerpc/sigcode32.S -r295186 = in place so that signal delivery maintains the modulo 16 byte = stack/frame alignment status instead of changing the alignment. >=20 > buildkernel was via gcc 4.2.1 > buildworld was via clang 3.8.0 >=20 >=20 >=20 > I'm not sure that I'm going to get much farther in tracking down the = source of the race(?) that leads to the SEGV's. I should have given an example of clang 3.8.0 produced post-amble code = that ends up picking up the 0x0 and putting it is r31 (the Frame Pointer = for clang's produced code). 0x1801b8c : lwz r30,24(r31) 0x1801b90 : lwz r29,20(r31) 0x1801b94 : lwz r28,16(r31) 0x1801b98 : lwz r27,12(r31) 0x1801b9c : lwz r26,8(r31) 0x1801ba0 : addi r1,r1,32 # Stack pointer = adjusted first 0x1801ba4 : lwz r0,4(r1) 0x1801ba8 : lwz r31,-4(r1) # Then Frame Pointer = load happens # "outside" the new = stack range. 0x1801bac : mtlr r0 0x1801bb0 : blr Here is the related bl and following code: 0x182516c : bl 0x1801b24 0x1825170 : lis r3,396 =3D> 0x1825174 : lwz r4,16(r31) 0x1825178 : lwz r3,-13260(r3) 0x182517c : subf. r3,r4,r3 0x1825180 : bne 0x18251c4 = The "=3D>" points to a "sometimes SEGV" place from r31=3D0x0 being = involved in a clang 3.8.0 buildworld's based "make" after it resumes = normal operation after handling a SIGCHLD delivery. So the "lwz r31,-4(r1)" earlier above resulted in a 0x0 in r31 just = before the SEGV. By contrast the gcc 4.2.1 generated code does not use r31 as a frame = pointer and has: 0x1801db8 : lwz r0,52(r1) 0x1801dbc : lwz r27,28(r1) 0x1801dc0 : lwz r28,32(r1) 0x1801dc4 : mtlr r0 0x1801dc8 : lwz r29,36(r1) 0x1801dcc : lwz r30,40(r1) 0x1801dd0 : lwz r31,44(r1) 0x1801dd4 : addi r1,r1,48 # Stack pointer is = adjusted last. # The prior code = worked in the range. 0x1801dd8 : blr and: 0x1823cac : bl 0x1801d58 0x1823cb0 : b 0x1823c0c . . . backing up to the jump point . . . 0x1823c0c : lwz r0,28(r1) # Stack pointer used, = not a Frame Pointer 0x1823c10 : lwz r9,0(r25) 0x1823c14 : xor. r0,r0,r9 0x1823c18 : li r9,0 0x1823c1c : li r3,1 0x1823c20 : bne- 0x1823cb4 As r31 is not used as a frame pointer the 4.2.1 code can not get the = SEGV that the clang 3.8.0 code sometimes gets. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Fri Feb 5 16:11:20 2016 Return-Path: Delivered-To: freebsd-ppc@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 2C24BA9B48B for ; Fri, 5 Feb 2016 16:11:20 +0000 (UTC) (envelope-from mma@semihalf.com) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0053D1B02 for ; Fri, 5 Feb 2016 16:11:19 +0000 (UTC) (envelope-from mma@semihalf.com) Received: by mail-ig0-x231.google.com with SMTP id xg9so16688761igb.1 for ; Fri, 05 Feb 2016 08:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=6Hyaoh7vhb6dhOTSxbuRqVJ3GkdS8Jm3HdVds/6fcC0=; b=fISPr1wP6oxpfCaUEfBBFy2Q2GgEzNUVMEj/yawXIPje1F53Cno5anPKN50PEvSXFr DDzzEVZjfeYG1qOweTCTPBE+tY5vlVZwgu8YKD4ef+wQUgc0TnXXbS68xuq23qPDY7eF OXQsJxsCq463UOsKu3XJUYUwFg5ws79T4ZAHY2IpJIgGRFCX/wI8vjTzgKMUxaFJXNMS kI/RycjkGdZaV1yzgasYthqgxVTFy9tH4I+VnH+Jm+LJvmqh2JTaOJ2bcXCnN9nqCaft ZgvCV0bhRoyJmS/AOF5rIV/Xs7yI4Erd3yOS+y6hmTgMFQZQoMEKoWbtjMrVPBwZt6Di F4zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=6Hyaoh7vhb6dhOTSxbuRqVJ3GkdS8Jm3HdVds/6fcC0=; b=gGrguQF2tghwhrVnJ0eSZw4Ac2BcVb/a0PmB8Nvvame2r3d4ZqAm6T4R2HsShd+7hm 7oq2rE0/xD8TzuY5+0r7sVsCc06ePjIyYmLlqoMVM89BoBbJrh9xWgvXin04QM8JIp22 cc0fh09o0Xwj0BIjVMyV4k3sdEseO0b5+DdhPwqgx1ioboY4dBNXrSGInrkt4dLOdk+P 9Kul3YCJAw8lRDIVXbXchyFy5UebLnV5wK1hSDvYH67XZQ9ZFoXLUGbRsBrPwXl3Hn8n dJFfhEix2TbZXVBysaYziB2biocHLqvSyCEjz+zl5KMREWf//ARsBGI/K37hDebquJBT /u4Q== X-Gm-Message-State: AG10YOSE1xt8cTAgMMDsyofWaawJKiKfLu4uSD3HzIGxsl1AeOR0U6QbVBGz/Q9UiQG028/Yl64kMc5hRJErtg== MIME-Version: 1.0 X-Received: by 10.50.141.193 with SMTP id rq1mr10494630igb.44.1454688679152; Fri, 05 Feb 2016 08:11:19 -0800 (PST) Received: by 10.107.4.8 with HTTP; Fri, 5 Feb 2016 08:11:19 -0800 (PST) Date: Fri, 5 Feb 2016 17:11:19 +0100 Message-ID: Subject: Request for testing bus_get_bus_tag() nexus method From: Marcin Mazurek To: freebsd-current@freebsd.org, freebsd-arm@freebsd.org, freebsd-ppc@freebsd.org, freebsd-mips@freebsd.org Content-Type: multipart/mixed; boundary=089e013cbd68fb4ebc052b08198f X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:11:20 -0000 --089e013cbd68fb4ebc052b08198f Content-Type: text/plain; charset=UTF-8 Hello, I am looking for testers for a patch to add BUS_GET_BUS_TAG method to some platforms nexus that return per platform specific default tag. It works fine on arm, but I do not have any powerpc or mips hardware to test it on, so I would like it if this could be tested on these platforms using this code to check if it does not break them. Any comments and feedback are welcome. Thanks, Marcin --089e013cbd68fb4ebc052b08198f Content-Type: text/plain; charset=US-ASCII; name="nexus-get-bus-tag-method.diff" Content-Disposition: attachment; filename="nexus-get-bus-tag-method.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ik9vwdc10 ZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL25leHVzLmMgYi9zeXMvYXJtL2FybS9uZXh1cy5jCmlu ZGV4IDhkY2UzNmMuLmUxZTk4M2YgMTAwNjQ0Ci0tLSBhL3N5cy9hcm0vYXJtL25leHVzLmMKKysr IGIvc3lzL2FybS9hcm0vbmV4dXMuYwpAQCAtODUsNiArODUsNyBAQCBzdGF0aWMJc3RydWN0IHJl c291cmNlICpuZXh1c19hbGxvY19yZXNvdXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwgaW50 ICosCiAgICAgdV9sb25nLCB1X2xvbmcsIHVfbG9uZywgdV9pbnQpOwogc3RhdGljCWludCBuZXh1 c19hY3RpdmF0ZV9yZXNvdXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwgaW50LAogICAgIHN0 cnVjdCByZXNvdXJjZSAqKTsKK3N0YXRpYyBidXNfc3BhY2VfdGFnX3QgbmV4dXNfZ2V0X2J1c190 YWcoZGV2aWNlX3QsIGRldmljZV90KTsKICNpZmRlZiBBUk1fSU5UUk5HCiAjaWZkZWYgU01QCiBz dGF0aWMJaW50IG5leHVzX2JpbmRfaW50cihkZXZpY2VfdCwgZGV2aWNlX3QsIHN0cnVjdCByZXNv dXJjZSAqLCBpbnQpOwpAQCAtMTI0LDYgKzEyNSw3IEBAIHN0YXRpYyBkZXZpY2VfbWV0aG9kX3Qg bmV4dXNfbWV0aG9kc1tdID0gewogCURFVk1FVEhPRChidXNfcmVsZWFzZV9yZXNvdXJjZSwJbmV4 dXNfcmVsZWFzZV9yZXNvdXJjZSksCiAJREVWTUVUSE9EKGJ1c19zZXR1cF9pbnRyLAluZXh1c19z ZXR1cF9pbnRyKSwKIAlERVZNRVRIT0QoYnVzX3RlYXJkb3duX2ludHIsCW5leHVzX3RlYXJkb3du X2ludHIpLAorCURFVk1FVEhPRChidXNfZ2V0X2J1c190YWcsCW5leHVzX2dldF9idXNfdGFnKSwK ICNpZmRlZiBBUk1fSU5UUk5HCiAJREVWTUVUSE9EKGJ1c19kZXNjcmliZV9pbnRyLAluZXh1c19k ZXNjcmliZV9pbnRyKSwKICNpZmRlZiBTTVAKQEAgLTI2MCw2ICsyNjIsMTcgQEAgbmV4dXNfcmVs ZWFzZV9yZXNvdXJjZShkZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50 IHJpZCwKIAlyZXR1cm4gKHJtYW5fcmVsZWFzZV9yZXNvdXJjZShyZXMpKTsKIH0KIAorc3RhdGlj IGJ1c19zcGFjZV90YWdfdAorbmV4dXNfZ2V0X2J1c190YWcoZGV2aWNlX3QgYnVzIF9fdW51c2Vk LCBkZXZpY2VfdCBjaGlsZCBfX3VudXNlZCkKK3sKKworI2lmZGVmIEZEVAorCQlyZXR1cm4oZmR0 YnVzX2JzX3RhZyk7CisjZWxzZQorCQlyZXR1cm4oKHZvaWQgKikxKTsKKyNlbmRpZgorfQorCiBz dGF0aWMgaW50CiBuZXh1c19jb25maWdfaW50cihkZXZpY2VfdCBkZXYsIGludCBpcnEsIGVudW0g aW50cl90cmlnZ2VyIHRyaWcsCiAgICAgZW51bSBpbnRyX3BvbGFyaXR5IHBvbCkKZGlmZiAtLWdp dCBhL3N5cy9hcm02NC9hcm02NC9uZXh1cy5jIGIvc3lzL2FybTY0L2FybTY0L25leHVzLmMKaW5k ZXggODA3OTkzYi4uMzQ3MzY0OSAxMDA2NDQKLS0tIGEvc3lzL2FybTY0L2FybTY0L25leHVzLmMK KysrIGIvc3lzL2FybTY0L2FybTY0L25leHVzLmMKQEAgLTExMiw2ICsxMTIsNyBAQCBzdGF0aWMJ aW50IG5leHVzX2RlYWN0aXZhdGVfcmVzb3VyY2UoZGV2aWNlX3QsIGRldmljZV90LCBpbnQsIGlu dCwKIHN0YXRpYyBpbnQgbmV4dXNfc2V0dXBfaW50cihkZXZpY2VfdCBkZXYsIGRldmljZV90IGNo aWxkLCBzdHJ1Y3QgcmVzb3VyY2UgKnJlcywKICAgICBpbnQgZmxhZ3MsIGRyaXZlcl9maWx0ZXJf dCAqZmlsdCwgZHJpdmVyX2ludHJfdCAqaW50ciwgdm9pZCAqYXJnLCB2b2lkICoqY29va2llcCk7 CiBzdGF0aWMgaW50IG5leHVzX3RlYXJkb3duX2ludHIoZGV2aWNlX3QsIGRldmljZV90LCBzdHJ1 Y3QgcmVzb3VyY2UgKiwgdm9pZCAqKTsKK3N0YXRpYyBidXNfc3BhY2VfdGFnX3QgbmV4dXNfZ2V0 X2J1c190YWcoZGV2aWNlX3QsIGRldmljZV90KTsKIAogI2lmZGVmIEZEVAogc3RhdGljIGludCBu ZXh1c19vZndfbWFwX2ludHIoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgcGhhbmRsZV90 IGlwYXJlbnQsCkBAIC0xMzAsNiArMTMxLDcgQEAgc3RhdGljIGRldmljZV9tZXRob2RfdCBuZXh1 c19tZXRob2RzW10gPSB7CiAJREVWTUVUSE9EKGJ1c19kZWFjdGl2YXRlX3Jlc291cmNlLAluZXh1 c19kZWFjdGl2YXRlX3Jlc291cmNlKSwKIAlERVZNRVRIT0QoYnVzX3NldHVwX2ludHIsCW5leHVz X3NldHVwX2ludHIpLAogCURFVk1FVEhPRChidXNfdGVhcmRvd25faW50ciwJbmV4dXNfdGVhcmRv d25faW50ciksCisJREVWTUVUSE9EKGJ1c19nZXRfYnVzX3RhZywJbmV4dXNfZ2V0X2J1c190YWcp LAogCiAJeyAwLCAwIH0KIH07CkBAIC0yOTIsNiArMjk0LDEzIEBAIG5leHVzX3RlYXJkb3duX2lu dHIoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCwgc3RydWN0IHJlc291cmNlICpyLCB2b2lk ICppaCkKIAlyZXR1cm4gKGFybV90ZWFyZG93bl9pbnRyKGloKSk7CiB9CiAKK3N0YXRpYyBidXNf c3BhY2VfdGFnX3QKK25leHVzX2dldF9idXNfdGFnKGRldmljZV90IGJ1cyBfX3VudXNlZCwgZGV2 aWNlX3QgY2hpbGQgX191bnVzZWQpCit7CisKKwkJcmV0dXJuKCZtZW1tYXBfYnVzKTsKK30KKwog c3RhdGljIGludAogbmV4dXNfYWN0aXZhdGVfcmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2Vf dCBjaGlsZCwgaW50IHR5cGUsIGludCByaWQsCiAgICAgc3RydWN0IHJlc291cmNlICpyKQpkaWZm IC0tZ2l0IGEvc3lzL2tlcm4vYnVzX2lmLm0gYi9zeXMva2Vybi9idXNfaWYubQppbmRleCBiYWZh NDQ4Li5kMjliZmI5IDEwMDY0NAotLS0gYS9zeXMva2Vybi9idXNfaWYubQorKysgYi9zeXMva2Vy bi9idXNfaWYubQpAQCAtNjM3LDYgKzYzNywxNyBAQCBNRVRIT0QgYnVzX2RtYV90YWdfdCBnZXRf ZG1hX3RhZyB7CiB9IERFRkFVTFQgYnVzX2dlbmVyaWNfZ2V0X2RtYV90YWc7CiAKIC8qKgorICog QGJyaWVmIFJldHVybnMgYnVzX3NwYWNlX3RhZ190IGZvciB1c2Ugdy8gZGV2aWNlcyBvbiB0aGUg YnVzLgorICoKKyAqIEBwYXJhbSBfZGV2CQl0aGUgcGFyZW50IGRldmljZSBvZiBAcCBfY2hpbGQK KyAqIEBwYXJhbSBfY2hpbGQJdGhlIGRldmljZSB0byB3aGljaCB0aGUgdGFnIHdpbGwgYmVsb25n CisgKi8KK01FVEhPRCBidXNfc3BhY2VfdGFnX3QgZ2V0X2J1c190YWcgeworCWRldmljZV90CV9k ZXY7CisJZGV2aWNlX3QJX2NoaWxkOworfSBERUZBVUxUIGJ1c19nZW5lcmljX2dldF9idXNfdGFn OworCisvKioKICAqIEBicmllZiBBbGxvdyB0aGUgYnVzIHRvIGRldGVybWluZSB0aGUgdW5pdCBu dW1iZXIgb2YgYSBkZXZpY2UuCiAgKgogICogQHBhcmFtIF9kZXYJCXRoZSBwYXJlbnQgZGV2aWNl IG9mIEBwIF9jaGlsZApkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vc3Vicl9idXMuYyBiL3N5cy9rZXJu L3N1YnJfYnVzLmMKaW5kZXggYjExNTliNi4uZjg3OThkNSAxMDA2NDQKLS0tIGEvc3lzL2tlcm4v c3Vicl9idXMuYworKysgYi9zeXMva2Vybi9zdWJyX2J1cy5jCkBAIC00MDk1LDYgKzQwOTUsMjIg QEAgYnVzX2dlbmVyaWNfZ2V0X2RtYV90YWcoZGV2aWNlX3QgZGV2LCBkZXZpY2VfdCBjaGlsZCkK IH0KIAogLyoqCisgKiBAYnJpZWYgSGVscGVyIGZ1bmN0aW9uIGZvciBpbXBsZW1lbnRpbmcgQlVT X0dFVF9CVVNfVEFHKCkuCisgKgorICogVGhpcyBzaW1wbGUgaW1wbGVtZW50YXRpb24gb2YgQlVT X0dFVF9CVVNfVEFHKCkgc2ltcGx5IGNhbGxzIHRoZQorICogQlVTX0dFVF9CVVNfVEFHKCkgbWV0 aG9kIG9mIHRoZSBwYXJlbnQgb2YgQHAgZGV2LgorICovCitidXNfc3BhY2VfdGFnX3QKK2J1c19n ZW5lcmljX2dldF9idXNfdGFnKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQpCit7CisKKwkv KiBQcm9wYWdhdGUgdXAgdGhlIGJ1cyBoaWVyYXJjaHkgdW50aWwgc29tZW9uZSBoYW5kbGVzIGl0 LiAqLworCWlmIChkZXYtPnBhcmVudCAhPSBOVUxMKQorCQlyZXR1cm4gKEJVU19HRVRfQlVTX1RB RyhkZXYtPnBhcmVudCwgY2hpbGQpKTsKKwlyZXR1cm4gKE5VTEwpOworfQorCisvKioKICAqIEBi cmllZiBIZWxwZXIgZnVuY3Rpb24gZm9yIGltcGxlbWVudGluZyBCVVNfR0VUX1JFU09VUkNFKCku CiAgKgogICogVGhpcyBpbXBsZW1lbnRhdGlvbiBvZiBCVVNfR0VUX1JFU09VUkNFKCkgdXNlcyB0 aGUKQEAgLTQ1NzQsNiArNDU5MCwyMyBAQCBidXNfZ2V0X2RtYV90YWcoZGV2aWNlX3QgZGV2KQog fQogCiAvKioKKyAqIEBicmllZiBXcmFwcGVyIGZ1bmN0aW9uIGZvciBCVVNfR0VUX0JVU19UQUco KS4KKyAqCisgKiBUaGlzIGZ1bmN0aW9uIHNpbXBseSBjYWxscyB0aGUgQlVTX0dFVF9CVVNfVEFH KCkgbWV0aG9kIG9mIHRoZQorICogcGFyZW50IG9mIEBwIGRldi4KKyAqLworYnVzX3NwYWNlX3Rh Z190CitidXNfZ2V0X2J1c190YWcoZGV2aWNlX3QgZGV2KQoreworCWRldmljZV90IHBhcmVudDsK KworCXBhcmVudCA9IGRldmljZV9nZXRfcGFyZW50KGRldik7CisJaWYgKHBhcmVudCA9PSBOVUxM KQorCQlyZXR1cm4gKE5VTEwpOworCXJldHVybiAoQlVTX0dFVF9CVVNfVEFHKHBhcmVudCwgZGV2 KSk7Cit9CisKKy8qKgogICogQGJyaWVmIFdyYXBwZXIgZnVuY3Rpb24gZm9yIEJVU19HRVRfRE9N QUlOKCkuCiAgKgogICogVGhpcyBmdW5jdGlvbiBzaW1wbHkgY2FsbHMgdGhlIEJVU19HRVRfRE9N QUlOKCkgbWV0aG9kIG9mIHRoZQpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2VycGMvcG93ZXJwYy9uZXh1 cy5jIGIvc3lzL3Bvd2VycGMvcG93ZXJwYy9uZXh1cy5jCmluZGV4IDhhNGQ4MTUuLjU2MGE0NmEg MTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL3Bvd2VycGMvbmV4dXMuYworKysgYi9zeXMvcG93ZXJw Yy9wb3dlcnBjL25leHVzLmMKQEAgLTY2LDYgKzY2LDcgQEAgc3RhdGljIGJ1c19zZXR1cF9pbnRy X3QgbmV4dXNfc2V0dXBfaW50cjsKIHN0YXRpYyBidXNfdGVhcmRvd25faW50cl90IG5leHVzX3Rl YXJkb3duX2ludHI7CiBzdGF0aWMgYnVzX2FjdGl2YXRlX3Jlc291cmNlX3QgbmV4dXNfYWN0aXZh dGVfcmVzb3VyY2U7CiBzdGF0aWMgYnVzX2RlYWN0aXZhdGVfcmVzb3VyY2VfdCBuZXh1c19kZWFj dGl2YXRlX3Jlc291cmNlOworc3RhdGljIGJ1c19zcGFjZV90YWdfdCBuZXh1c19nZXRfYnVzX3Rh ZyhkZXZpY2VfdCwgZGV2aWNlX3QpOwogI2lmZGVmIFNNUAogc3RhdGljIGJ1c19iaW5kX2ludHJf dCBuZXh1c19iaW5kX2ludHI7CiAjZW5kaWYKQEAgLTg3LDYgKzg4LDcgQEAgc3RhdGljIGRldmlj ZV9tZXRob2RfdCBuZXh1c19tZXRob2RzW10gPSB7CiAJREVWTUVUSE9EKGJ1c19iaW5kX2ludHIs CW5leHVzX2JpbmRfaW50ciksCiAjZW5kaWYKIAlERVZNRVRIT0QoYnVzX2NvbmZpZ19pbnRyLAlu ZXh1c19jb25maWdfaW50ciksCisJREVWTUVUSE9EKGJ1c19nZXRfYnVzX3RhZywJbmV4dXNfZ2V0 X2J1c190YWcpLAogCiAJLyogb2Z3X2J1cyBpbnRlcmZhY2UgKi8KIAlERVZNRVRIT0Qob2Z3X2J1 c19tYXBfaW50ciwJbmV4dXNfb2Z3X21hcF9pbnRyKSwKQEAgLTE1NSw2ICsxNTcsMTMgQEAgbmV4 dXNfdGVhcmRvd25faW50cihkZXZpY2VfdCBidXMgX191bnVzZWQsIGRldmljZV90IGNoaWxkIF9f dW51c2VkLAogCXJldHVybiAocG93ZXJwY190ZWFyZG93bl9pbnRyKGloKSk7CiB9CiAKK3N0YXRp YyBidXNfc3BhY2VfdGFnX3QKK25leHVzX2dldF9idXNfdGFnKGRldmljZV90IGJ1cyBfX3VudXNl ZCwgZGV2aWNlX3QgY2hpbGQgX191bnVzZWQpCit7CisKKwlyZXR1cm4oJmJzX2JlX3RhZyk7Cit9 CisKICNpZmRlZiBTTVAKIHN0YXRpYyBpbnQKIG5leHVzX2JpbmRfaW50cihkZXZpY2VfdCBidXMg X191bnVzZWQsIGRldmljZV90IGNoaWxkIF9fdW51c2VkLApAQCAtMjI0LDQgKzIzMywzIEBAIG5l eHVzX2RlYWN0aXZhdGVfcmVzb3VyY2UoZGV2aWNlX3QgYnVzIF9fdW51c2VkLCBkZXZpY2VfdCBj aGlsZCBfX3VudXNlZCwKIAogCXJldHVybiAocm1hbl9kZWFjdGl2YXRlX3Jlc291cmNlKHIpKTsK IH0KLQpkaWZmIC0tZ2l0IGEvc3lzL3NwYXJjNjQvc3BhcmM2NC9uZXh1cy5jIGIvc3lzL3NwYXJj NjQvc3BhcmM2NC9uZXh1cy5jCmluZGV4IDMwMzc0ZTUuLmY1Y2U0NzIgMTAwNjQ0Ci0tLSBhL3N5 cy9zcGFyYzY0L3NwYXJjNjQvbmV4dXMuYworKysgYi9zeXMvc3BhcmM2NC9zcGFyYzY0L25leHVz LmMKQEAgLTk4LDYgKzk4LDcgQEAgc3RhdGljIGJ1c19iaW5kX2ludHJfdCBuZXh1c19iaW5kX2lu dHI7CiAjZW5kaWYKIHN0YXRpYyBidXNfZGVzY3JpYmVfaW50cl90IG5leHVzX2Rlc2NyaWJlX2lu dHI7CiBzdGF0aWMgYnVzX2dldF9kbWFfdGFnX3QgbmV4dXNfZ2V0X2RtYV90YWc7CitzdGF0aWMg YnVzX2dldF9idXNfdGFnX3QgbmV4dXNfZ2V0X2J1c190YWc7CiBzdGF0aWMgb2Z3X2J1c19nZXRf ZGV2aW5mb190IG5leHVzX2dldF9kZXZpbmZvOwogCiBzdGF0aWMgaW50IG5leHVzX2lubGlzdChj b25zdCBjaGFyICosIGNvbnN0IGNoYXIgKmNvbnN0ICopOwpAQCAtMTM1LDYgKzEzNiw3IEBAIHN0 YXRpYyBkZXZpY2VfbWV0aG9kX3QgbmV4dXNfbWV0aG9kc1tdID0gewogI2VuZGlmCiAJREVWTUVU SE9EKGJ1c19kZXNjcmliZV9pbnRyLAluZXh1c19kZXNjcmliZV9pbnRyKSwKIAlERVZNRVRIT0Qo YnVzX2dldF9kbWFfdGFnLAluZXh1c19nZXRfZG1hX3RhZyksCisJREVWTUVUSE9EKGJ1c19nZXRf YnVzX3RhZywJbmV4dXNfZ2V0X2J1c190YWcpLAogCiAJLyogb2Z3X2J1cyBpbnRlcmZhY2UgKi8K IAlERVZNRVRIT0Qob2Z3X2J1c19nZXRfZGV2aW5mbywJbmV4dXNfZ2V0X2RldmluZm8pLApAQCAt NTAyLDYgKzUwNCwxMyBAQCBuZXh1c19nZXRfZG1hX3RhZyhkZXZpY2VfdCBidXMgX191bnVzZWQs IGRldmljZV90IGNoaWxkIF9fdW51c2VkKQogCXJldHVybiAoJm5leHVzX2RtYXRhZyk7CiB9CiAK K3N0YXRpYyBidXNfc3BhY2VfdGFnX3QKK25leHVzX2dldF9idXNfdGFnKGRldmljZV90IGJ1cyBf X3VudXNlZCwgZGV2aWNlX3QgY2hpbGQgX191bnVzZWQpCit7CisKKwlyZXR1cm4gKCZuZXh1c19i dXN0YWcpOworfQorCiBzdGF0aWMgY29uc3Qgc3RydWN0IG9md19idXNfZGV2aW5mbyAqCiBuZXh1 c19nZXRfZGV2aW5mbyhkZXZpY2VfdCBidXMgX191bnVzZWQsIGRldmljZV90IGNoaWxkKQogewpk aWZmIC0tZ2l0IGEvc3lzL3N5cy9idXMuaCBiL3N5cy9zeXMvYnVzLmgKaW5kZXggNDJkM2EzZi4u OWNkMjE3NCAxMDA2NDQKLS0tIGEvc3lzL3N5cy9idXMuaAorKysgYi9zeXMvc3lzL2J1cy5oCkBA IC0zMCw2ICszMCw3IEBACiAjZGVmaW5lIF9TWVNfQlVTX0hfCiAKICNpbmNsdWRlIDxtYWNoaW5l L19saW1pdHMuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL19idXMuaD4KICNpbmNsdWRlIDxzeXMvX2J1 c19kbWEuaD4KICNpbmNsdWRlIDxzeXMvaW9jY29tLmg+CiAKQEAgLTM4Myw2ICszODQsOCBAQCBp bnQJYnVzX2dlbmVyaWNfZGV0YWNoKGRldmljZV90IGRldik7CiB2b2lkCWJ1c19nZW5lcmljX2Ry aXZlcl9hZGRlZChkZXZpY2VfdCBkZXYsIGRyaXZlcl90ICpkcml2ZXIpOwogYnVzX2RtYV90YWdf dAogCWJ1c19nZW5lcmljX2dldF9kbWFfdGFnKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQp OworYnVzX3NwYWNlX3RhZ190CisJYnVzX2dlbmVyaWNfZ2V0X2J1c190YWcoZGV2aWNlX3QgZGV2 LCBkZXZpY2VfdCBjaGlsZCk7CiBpbnQJYnVzX2dlbmVyaWNfZ2V0X2RvbWFpbihkZXZpY2VfdCBk ZXYsIGRldmljZV90IGNoaWxkLCBpbnQgKmRvbWFpbik7CiBzdHJ1Y3QgcmVzb3VyY2VfbGlzdCAq CiAJYnVzX2dlbmVyaWNfZ2V0X3Jlc291cmNlX2xpc3QgKGRldmljZV90LCBkZXZpY2VfdCk7CkBA IC00NDgsNiArNDUxLDcgQEAgaW50CWJ1c19hY3RpdmF0ZV9yZXNvdXJjZShkZXZpY2VfdCBkZXYs IGludCB0eXBlLCBpbnQgcmlkLAogaW50CWJ1c19kZWFjdGl2YXRlX3Jlc291cmNlKGRldmljZV90 IGRldiwgaW50IHR5cGUsIGludCByaWQsCiAJCQkJc3RydWN0IHJlc291cmNlICpyKTsKIGJ1c19k bWFfdGFnX3QgYnVzX2dldF9kbWFfdGFnKGRldmljZV90IGRldik7CitidXNfc3BhY2VfdGFnX3Qg YnVzX2dldF9idXNfdGFnKGRldmljZV90IGRldik7CiBpbnQJYnVzX2dldF9kb21haW4oZGV2aWNl X3QgZGV2LCBpbnQgKmRvbWFpbik7CiBpbnQJYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2aWNlX3Qg ZGV2LCBpbnQgdHlwZSwgaW50IHJpZCwKIAkJCSAgICAgc3RydWN0IHJlc291cmNlICpyKTsK --089e013cbd68fb4ebc052b08198f-- From owner-freebsd-ppc@freebsd.org Fri Feb 5 16:31:37 2016 Return-Path: Delivered-To: freebsd-ppc@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 91969A9BF51; Fri, 5 Feb 2016 16:31:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D737E3E; Fri, 5 Feb 2016 16:31:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22c.google.com with SMTP id rs20so44187560igc.0; Fri, 05 Feb 2016 08:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CVkMYG99vEPirn3IUoO1Q9Ikk8Jy/mWtYJ4R6ISC2Q4=; b=tFkNO/VDkVEzUYPB8FH0EcVLvxg5UFl3wrY/XxZO2X4cZgJ8olsSvJFDZVU1LCHnFv whaVIT/tg7LSpLC/duAhWn+xskTa33C4KOAHhlfB5JZ33QsQr0+j/GlrlmTC/gYwX2O/ 0V+hGSJabiqSAYYprgS1ZMNzPdmzvj+mR6SyD0HOHmNRlQ5NQgZ0y0RxDjd5MVf7G9Y0 39RY86veW1QPQ10cIohQNNWtRxGNEt7gA0Dk0KrFwrGVXmNHw2Areu7ncUSEJq0dkBnN Oi4W8Sy3I2PDOn0/FCWFR9IJWwJeOe940sqGy7GrQKW+vEUUXP9ITPqf6n3TS7TbTrw8 jESA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CVkMYG99vEPirn3IUoO1Q9Ikk8Jy/mWtYJ4R6ISC2Q4=; b=jiLCbz8tw+zEqaVjFR+IsHLhxeahtujG7poaKwOELsjXQ2HIoPi5WLQyr5+5YBwWi7 79li0ElYAkc4iVxyNgTAGcCJfKoGWOtCvkt43PiASChRzGSANRVTQT+1ptEA3U0od4A+ yTTLeKZyeQPTpv3+fIrI5FXQ9qsRq3RrdZs1aQ9TVyJDgs3FWilK1/5tERO8oriej3P2 AFlBeK94V8dELGHBNaw9jzIspycFMmhxEAw6hPjoyaAwgMWw4leiRVYCD0MriSZdNAwD RfrY+Fd75P0aw7UprDtgB4aXjc0gwvk0g8EaOoLkFf641DIX3kCx6IFlbTAg8PsyFor3 YJYA== X-Gm-Message-State: AG10YOS5k8zTKjcUCtKpM2AdoZxrr3FIdw6s7CJiE8S3plMADcH9cl+oBttDcgw7TwzSR0Ty3K/+5feh6a8Z8Q== MIME-Version: 1.0 X-Received: by 10.50.93.36 with SMTP id cr4mr15602362igb.22.1454689896811; Fri, 05 Feb 2016 08:31:36 -0800 (PST) Received: by 10.36.14.19 with HTTP; Fri, 5 Feb 2016 08:31:36 -0800 (PST) In-Reply-To: References: Date: Fri, 5 Feb 2016 08:31:36 -0800 Message-ID: Subject: Re: Request for testing bus_get_bus_tag() nexus method From: Adrian Chadd To: Marcin Mazurek Cc: freebsd-current , "freebsd-arm@freebsd.org" , FreeBSD PowerPC ML , "freebsd-mips@freebsd.org" , Zbigniew Bodek Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 16:31:37 -0000 hi, you can run mips and powerpc inside qemu emulators. There's no reason to not test it! -adrian On 5 February 2016 at 08:11, Marcin Mazurek wrote: > Hello, > > I am looking for testers for a patch to add BUS_GET_BUS_TAG method to some > platforms nexus that return per platform specific default tag. > > It works fine on arm, but I do not have any powerpc or mips hardware to > test it on, > so I would like it if this could be tested on these platforms using this > code to check > if it does not break them. > > Any comments and feedback are welcome. > > Thanks, > Marcin > > _______________________________________________ > freebsd-mips@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-mips > To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Fri Feb 5 20:49:40 2016 Return-Path: Delivered-To: freebsd-ppc@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 BA819A9C7DC; Fri, 5 Feb 2016 20:49:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 99DBE7F7; Fri, 5 Feb 2016 20:49:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 937ECB948; Fri, 5 Feb 2016 15:49:39 -0500 (EST) From: John Baldwin To: freebsd-ppc@freebsd.org Cc: Marcin Mazurek , freebsd-current@freebsd.org, freebsd-arm@freebsd.org, freebsd-mips@freebsd.org Subject: Re: Request for testing bus_get_bus_tag() nexus method Date: Fri, 05 Feb 2016 12:49:17 -0800 Message-ID: <1784059.mPpRYc4e0u@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 05 Feb 2016 15:49:39 -0500 (EST) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 20:49:40 -0000 On Friday, February 05, 2016 05:11:19 PM Marcin Mazurek wrote: > Hello, > > I am looking for testers for a patch to add BUS_GET_BUS_TAG method to some > platforms nexus that return per platform specific default tag. > > It works fine on arm, but I do not have any powerpc or mips hardware to > test it on, > so I would like it if this could be tested on these platforms using this > code to check > if it does not break them. > > Any comments and feedback are welcome. I'm guess you mean this for memory access? Have you thought about accepting the resource type so you can do: bus_get_bus_tag(dev, SYS_RES_MEMORY); vs bus_get_bus_tag(dev, SYS_RES_IOPORT); I would also be inclined to call it 'bus_get_bus_space_tag()' since it is returning a bus_space tag. "bus tag" might too generic of a name. In general though it seems to be a workaround for not wanting to allocate an actual resource with bus_alloc_resource() and then using bus_activate_resource() to obtain a valid (tag, handle) tuple? -- John Baldwin From owner-freebsd-ppc@freebsd.org Sat Feb 6 15:38:04 2016 Return-Path: Delivered-To: freebsd-ppc@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 F0D35A9F61F for ; Sat, 6 Feb 2016 15:38:04 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B47C610F7 for ; Sat, 6 Feb 2016 15:38:04 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id x21so58292402oix.3 for ; Sat, 06 Feb 2016 07:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=io9VpHbCi6KgM2ZuN2eO88sgFA3sfCERNNHAfgcksYE=; b=YauSh8Ep2JBSpCka66sMp/25SWvesD6Q0ZFmpmQKPxdEt6Wb1F3aCN55rgWujAigYI Gt+vrrcjbVROqZVQHc5nNzPhtZaeEBaSGCBz2YSnFrM7GHqJOzeK4pIYuYpMZZIDGj1X K8+JG5c9VS5RRV3XKBjp8UstPtlEiT/xdc3kUWIGFTnd4pkJazP9K2vpS8jYxWZG7Fd4 eXVg5EVpykQQuORsQU28Dyql6jc37/MiDyo5VwInhhS7SgDpkupzu47IT7irrsTrCsXj 1c+Czsz976OpQS0oLGdwlL3DQ2kuhvpXzCUIR/gnbvZ7t75KJhK9qa6Qd6qAvEMbjpkM m3Wg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=io9VpHbCi6KgM2ZuN2eO88sgFA3sfCERNNHAfgcksYE=; b=KPnwYk6EQLQ5abygSFnS5Ii7WtngKvd1H4sApgseKjVeuIaQNsNgO2jK0/JoNVtc5C FwlqtYlsl6VyNznlVW2Ym6/sCuYQUJKVzutJMM7S40w6sHj9QorrF7sirOylP132tOHZ KFAi14uqRns4iFYcRDXzAqlYyLRcfz4H2tCqlEcIVOphntk4PobI9CMQsFgFHsHXngLF A3egcJVkzWaaB6GJ/xEoyH+Nu6Dt7FQy+UdMj93T6NDQA3pGTrb6A/TDpISef5+BVi0b O/1bn4yVH3uNFDNfSICPjg8sxMmJvSMZImCsUe3YuNbdXQ1e0kEThjdsslSow9RbxdnZ N1Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=io9VpHbCi6KgM2ZuN2eO88sgFA3sfCERNNHAfgcksYE=; b=C+SRs602aNZBDFv7OVBFD1ESXL7g45V9FDNEQUl5X2VHZQgJkzLPISWwspu+b7gTIs msdcLXuDLqiQnmmKLz29AwtjN0eiedd53ePy1HpabZShwqidvFyg1Ele77d8AvJ4Hxtq bsr33sn4XvfQA6hOX5eK13ZJ2chmKle9s3pOTFU8N36I8GmzE2QUROv5iLTrsVPvHa7X byWwyIJNh2sTeIa7sZsw+ByO8xwfPlzYb5r7nCgjyAOfDAbnJxpN/Fq07vi4PRDeSs65 WyZxA5/qokXWNCh/KWtLJUahDtSP132rd9BxfFnbwNTzMnPDoDogmG6IMN6KPDYy6Uht HdyQ== X-Gm-Message-State: AG10YOSMPjwLaL4nqqhVot/uVaQ1Isbctd4nBJ7xHBm7Kv7gvdMrk9CjxVDwzp2U1UBSHKQTcFzz8U690kzPWQ== MIME-Version: 1.0 X-Received: by 10.202.59.138 with SMTP id i132mr12557851oia.3.1454773083877; Sat, 06 Feb 2016 07:38:03 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.182.74.101 with HTTP; Sat, 6 Feb 2016 07:38:03 -0800 (PST) Received: by 10.182.74.101 with HTTP; Sat, 6 Feb 2016 07:38:03 -0800 (PST) Date: Sat, 6 Feb 2016 09:38:03 -0600 X-Google-Sender-Auth: PDW47YnIGLwtwc6i-5ixzc56jNM Message-ID: Subject: POWER8 workstation From: Justin Hibbits To: FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 15:38:05 -0000 Interesting find: https://raptorengineeringinc.com/TALOS/prerelease.php Still in prerelease, but it's only $3100, so quite tempting, and could make for a good target. - Justin From owner-freebsd-ppc@freebsd.org Sat Feb 6 16:47:20 2016 Return-Path: Delivered-To: freebsd-ppc@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 5EDA3AA0EC7 for ; Sat, 6 Feb 2016 16:47:20 +0000 (UTC) (envelope-from trix@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F19C7EC8 for ; Sat, 6 Feb 2016 16:47:19 +0000 (UTC) (envelope-from trix@juniper.net) Received: from BY2PR0501MB2005.namprd05.prod.outlook.com (10.163.197.16) by BY2PR0501MB2008.namprd05.prod.outlook.com (10.163.197.19) with Microsoft SMTP Server (TLS) id 15.1.403.16; Sat, 6 Feb 2016 16:33:07 +0000 Received: from BY2PR0501MB2005.namprd05.prod.outlook.com ([10.163.197.16]) by BY2PR0501MB2005.namprd05.prod.outlook.com ([10.163.197.16]) with mapi id 15.01.0403.016; Sat, 6 Feb 2016 16:33:06 +0000 From: Thomas Rix To: Justin Hibbits , FreeBSD PowerPC ML Subject: Re: POWER8 workstation Thread-Topic: POWER8 workstation Thread-Index: AQHRYPRixKCUAdbevUS3TR2PIXYE4Z8esBSA Date: Sat, 6 Feb 2016 16:33:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 authentication-results: alumni.cwru.edu; dkim=none (message not signed) header.d=none;alumni.cwru.edu; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.14] x-microsoft-exchange-diagnostics: 1; BY2PR0501MB2008; 5:M6Ln+mR2EocaX/0vsZ68p8mOESePnfo8zbBXn9Sl3PfLOcDYaOaoYXHQVxVICohPH692CpWEo0zjeG+M9N96k6GnIV2MSlEhhN1nnahmcqgML5PMEis3Ph7fVy9KmON6KatEuX6n7F96cFoc9U0vlg==; 24:sUN08/86aVkw+7HtirbEse5XY0FoEdKNTXKxAAiJml17uetLXc2d75BtrB5DmIIgd2haqzGHBjDWlI5+XhB+/ghUOiWZ+Fqvuw/L1SGYh10= x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(42134001)(42139001); SRVR:BY2PR0501MB2008; x-ms-office365-filtering-correlation-id: fad2e9b6-7964-433d-3f2f-08d32f133154 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BY2PR0501MB2008; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB2008; x-forefront-prvs: 08444C7C87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(377454003)(24454002)(92566002)(2906002)(87936001)(5008740100001)(107886002)(5004730100002)(2171001)(86362001)(19580405001)(3846002)(586003)(5002640100001)(1096002)(122556002)(40100003)(1220700001)(102836003)(19580395003)(66066001)(83506001)(189998001)(15975445007)(4001350100001)(3280700002)(2950100001)(77096005)(76176999)(50986999)(16799955002)(106116001)(36756003)(10400500002)(3660700001)(54356999)(5001960100002)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB2008; H:BY2PR0501MB2005.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2016 16:33:06.6767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB2008 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 16:47:20 -0000 Yes $3100 is a bargain compared to $4000 for a p5040 :P --- Tom Rix Sr. Staff Compiler Engineer trix@juniper.net On 2/6/16, 7:38 AM, "owner-freebsd-ppc@freebsd.org on behalf of Justin Hibbits" wrote: >Interesting find: https://raptorengineeringinc.com/TALOS/prerelease.php > >Still in prerelease, but it's only $3100, so quite tempting, and could >make >for a good target. > >- Justin >_______________________________________________ >freebsd-ppc@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"