Date: Sun, 23 Oct 2011 11:43:30 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Roman Divacky <rdivacky@freebsd.org> 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: <20111023084330.GA50300@deviant.kiev.zoral.com.ua> In-Reply-To: <20111023082412.GA74520@freebsd.org> References: <20111022205129.32569ec5@davenulle.org> <20111023082412.GA74520@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--8Y8a5CJOPM/zJV44
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Oct 23, 2011 at 10:24:12AM +0200, Roman Divacky wrote:
> > Program received signal SIGILL, Illegal instruction.
> > 0x08048b24 in do_typedef (s=3D0x80532bf "CUMULATIVE_ARGS", pos=3D0x805e=
1a4)
> > at /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtyp=
e.c:103
> > 103 {
> >=20
> > (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)
>=20
> LLVM attempts to use an optimal nop sequence when writing N-byte nop,
> by using these nop instructions
>=20
> static const uint8_t Nops[10][10] =3D {
> // 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},
> };
>=20
> There's no checking for a supported CPU, is it so that AMD geode doesnt s=
upport any of these?
> Any other cpu that doesnt support these? If this is CPU dependant, I sugg=
est 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.
--8Y8a5CJOPM/zJV44
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iEYEARECAAYFAk6j07EACgkQC3+MBN1Mb4jKGgCePnVGFf8bcwIJj4CGnN/gzw7V
tv0AoL19C0JxUJyoR/BXubZJQoBO8YUQ
=6+hY
-----END PGP SIGNATURE-----
--8Y8a5CJOPM/zJV44--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111023084330.GA50300>