Date: Sun, 23 Oct 2011 12:11:05 +0200 From: Roman Divacky <rdivacky@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, Patrick Lamaiziere <patfbsd@davenulle.org> Subject: Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586. Message-ID: <20111023101105.GA87729@freebsd.org> In-Reply-To: <20111023084330.GA50300@deviant.kiev.zoral.com.ua> References: <20111022205129.32569ec5@davenulle.org> <20111023082412.GA74520@freebsd.org> <20111023084330.GA50300@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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.
>
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111023101105.GA87729>