[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
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 cla
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
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 0
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.
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
[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
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
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
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 a
10 matches
Mail list logo
