3 quick questions about stack alignment for powerpc (32-bit) signal handlers

Mark Millard markmi at dsl-only.net
Mon Feb 1 02:32:42 UTC 2016


[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 <chmeeedalf at gmail.com> 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 <rdivacky at vlakno.cz> 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 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe at freebsd.org"
> 




More information about the freebsd-ppc mailing list