From owner-freebsd-current@FreeBSD.ORG Sun Oct 23 10:11:10 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15C24106566C for ; Sun, 23 Oct 2011 10:11:10 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id CEEF18FC08 for ; Sun, 23 Oct 2011 10:11:09 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id E36687F3822; Sun, 23 Oct 2011 12:11:05 +0200 (CEST) Date: Sun, 23 Oct 2011 12:11:05 +0200 From: Roman Divacky To: Kostik Belousov Message-ID: <20111023101105.GA87729@freebsd.org> References: <20111022205129.32569ec5@davenulle.org> <20111023082412.GA74520@freebsd.org> <20111023084330.GA50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111023084330.GA50300@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current , Patrick Lamaiziere Subject: Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 10:11:10 -0000 On Sun, Oct 23, 2011 at 11:43:30AM +0300, Kostik Belousov wrote: > On Sun, Oct 23, 2011 at 10:24:12AM +0200, Roman Divacky wrote: > > > Program received signal SIGILL, Illegal instruction. > > > 0x08048b24 in do_typedef (s=0x80532bf "CUMULATIVE_ARGS", pos=0x805e1a4) > > > at /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c:103 > > > 103 { > > > > > > (gdb) disas 0x08048b24 > > > Dump of assembler code for function do_typedef: > > > 0x08048b10 : push %ebp > > > 0x08048b11 : mov %esp,%ebp > > > 0x08048b13 : push %ebx > > > 0x08048b14 : push %edi > > > 0x08048b15 : push %esi > > > 0x08048b16 : sub $0xc,%esp > > > 0x08048b19 : mov $0x805e1d4,%edi > > > 0x08048b1e : mov 0x10(%ebp),%esi > > > 0x08048b21 : mov 0x8(%ebp),%ebx > > > 0x08048b24 : nopw %cs:0x0(%eax,%eax,1) > > > > LLVM attempts to use an optimal nop sequence when writing N-byte nop, > > by using these nop instructions > > > > static const uint8_t Nops[10][10] = { > > // nop > > {0x90}, > > // xchg %ax,%ax > > {0x66, 0x90}, > > // nopl (%[re]ax) > > {0x0f, 0x1f, 0x00}, > > // nopl 0(%[re]ax) > > {0x0f, 0x1f, 0x40, 0x00}, > > // nopl 0(%[re]ax,%[re]ax,1) > > {0x0f, 0x1f, 0x44, 0x00, 0x00}, > > // nopw 0(%[re]ax,%[re]ax,1) > > {0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00}, > > // nopl 0L(%[re]ax) > > {0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00}, > > // nopl 0L(%[re]ax,%[re]ax,1) > > {0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, > > // nopw 0L(%[re]ax,%[re]ax,1) > > {0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, > > // nopw %cs:0L(%[re]ax,%[re]ax,1) > > {0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00}, > > }; > > > > There's no checking for a supported CPU, is it so that AMD geode doesnt support any of these? > > Any other cpu that doesnt support these? If this is CPU dependant, I suggest to open a bug > > report upstream as it's a bug. > > Long nops are supported only on specific CPUs. Unconditional use of them > is a plain bug, like unconditional use of cmovXX. Yes, it's a bug, I filed http://llvm.org/bugs/show_bug.cgi?id=11212 upstream. Patric, as a temporary workaround please add "-no-integrated-as" to your CFLAGS, that will make clang use gnu as instead of its own intergrated assembler, thus avoiding this problem. Thanks for the great analysis! roman