From owner-freebsd-current@FreeBSD.ORG  Sun Oct 23 08:24:16 2011
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 E6AC9106566B
	for <freebsd-current@freebsd.org>; Sun, 23 Oct 2011 08:24:16 +0000 (UTC)
	(envelope-from rdivacky@vlakno.cz)
Received: from vlakno.cz (vlakno.cz [46.28.110.116])
	by mx1.freebsd.org (Postfix) with ESMTP id A93868FC08
	for <freebsd-current@freebsd.org>; Sun, 23 Oct 2011 08:24:16 +0000 (UTC)
Received: by vlakno.cz (Postfix, from userid 1002)
	id 9E4357F3822; Sun, 23 Oct 2011 10:24:12 +0200 (CEST)
Date: Sun, 23 Oct 2011 10:24:12 +0200
From: Roman Divacky <rdivacky@freebsd.org>
To: Patrick Lamaiziere <patfbsd@davenulle.org>
Message-ID: <20111023082412.GA74520@freebsd.org>
References: <20111022205129.32569ec5@davenulle.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20111022205129.32569ec5@davenulle.org>
User-Agent: Mutt/1.4.2.3i
Cc: FreeBSD Current <freebsd-current@freebsd.org>
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Oct 2011 08:24:17 -0000

> 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 <do_typedef+0>:      push   %ebp
> 0x08048b11 <do_typedef+1>:      mov    %esp,%ebp
> 0x08048b13 <do_typedef+3>:      push   %ebx
> 0x08048b14 <do_typedef+4>:      push   %edi
> 0x08048b15 <do_typedef+5>:      push   %esi
> 0x08048b16 <do_typedef+6>:      sub    $0xc,%esp
> 0x08048b19 <do_typedef+9>:      mov    $0x805e1d4,%edi
> 0x08048b1e <do_typedef+14>:     mov    0x10(%ebp),%esi
> 0x08048b21 <do_typedef+17>:     mov    0x8(%ebp),%ebx
> 0x08048b24 <do_typedef+20>:     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.

roman