On Sun, Oct 4, 2015 at 10:51 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Sun, Oct 4, 2015 at 1:00 PM, Uros Bizjak <ubiz...@gmail.com> wrote: >> On Sun, Oct 4, 2015 at 8:15 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >> >>>> Looking a bit deeper into the code, it looks that we want to realign >>>> the stack in the interrupt handler. Let's assume that interrupt >>>> handler is calling some other function that saves SSE vector regs to >>>> the stack. According to the x86 ABI, incoming stack of the called >>>> function is assumed to be aligned to 16 bytes. But, interrupt handler >>>> violates this assumption, since the stack could be aligned to only 4 >>>> bytes for 32bit and 8 bytes for 64bit targets. Entering the called >>>> function with stack, aligned to less than 16 bytes will certainly >>>> violate ABI. >>>> >>>> So, it looks to me that we need to realign the stack in the interrupt >>>> handler unconditionally to 16bytes. In this case, we also won't need >>>> the following changes: >>>> >>> >>> Current stack alignment implementation requires at least >>> one, maybe two, scratch registers: >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67841 >>> >>> Extend it to the interrupt handler, which doesn't have any scratch >>> registers may require significant changes in backend as well as >>> register allocator. >> >> But without realignment, the handler is unusable for anything but >> simple functions. The handler will crash when called function will try >> to save vector reg to stack. >> > > We can use unaligned load and store to avoid crash.
Oh, sorry, I meant "called function will crash", like: -> interrupt when %rsp = 0x...8 -> -> interrupt handler -> -> calls some function that tries to save xmm reg to stack -> crash in the called function Uros.