Re: problems with cvsup on FreeBSD 9 snapshot 201101

From: Eric McCorkle <eric_at_shadowsun.net>
Date: Wed, 15 Jun 2011 20:49:44 -0400
On 6/15/11 10:58 AM, Kostik Belousov wrote:
> On Wed, Jun 15, 2011 at 10:24:46AM -0400, Eric McCorkle wrote:
>> On 6/15/11 8:23 AM, Holger Kipp wrote:
>>> Dear all,
>>>
>>> I had installed FreeBSD 9 amd64 from snapshot (ISO-image) located here:
>>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/201101/FreeBSD-9.0-CURRENT-201101-amd64-dvd1.iso
>>>
>>>
>>> Today I wanted to cvsup to a later date to upgrade to ZFS v28
>>> and compiled port /usr/ports/net/cvsup-without-gui without problems.
>>>
>>> Starting freshly compiled cvsup then gives me
>>>
>>> "Illegal Instruction"
>>>
>>> This error seems to be identical to
>>> http://lists.freebsd.org/pipermail/freebsd-current/2010-September/020083.html
>>>
>>
>> I've gotten the same problem, and managed to diagnose it.  The problem
>> actually isn't an illegal instruction, but a stack misalignment.  If you
>> load it in gdb, it will die with SIGSEGV somewhere in libc.so.7, on a
>> callq instruction.  This is because callq needs the stack to be 16-byte
>> aligned, and it's not for some reason.
> Stack alignment requirement is an ABI convention, and it is not enforced
> by CPU, except several special cases. In particular, either EFLAGS.AC
> bit should be set, that usually is not, or SSE instruction explicitely
> disallowing non-aligned access executed. Anyway, you will not get
> Illegal instruction fault for unaligned access.

I took a closer look this afternoon, and you're right.  callq with an 
unaligned stack pointer does *not* cause a fault.  If anyone does a 
movaps, however, you will get a fault (SIGBUS, I believe), and if the 
ABI says stacks are 16-byte aligned, then libraries may assume it's safe 
to load from the stack with movaps, and you'll get a fault.  This is 
what happened to mlton on Mac OS, so I thought it might be something 
similar going on here.

Anyways, I'll look into it more.
Received on Wed Jun 15 2011 - 22:49:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:14 UTC