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 poi
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 si
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
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 wit
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
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
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
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
[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
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'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.
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
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
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
14 matches
Mail list logo
