From owner-freebsd-toolchain@freebsd.org Mon Feb 1 02:32:42 2016 Return-Path: Delivered-To: freebsd-toolchain@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 161DFA75717 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 D05E11EEC for ; Mon, 1 Feb 2016 02:32:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13125 invoked from network); 1 Feb 2016 02:32:52 -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:52 -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-toolchain@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain 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