Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
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: mov0x10(%ebp),%esi
0x08048b21 do_typedef+17: mov0x8(%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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
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: mov0x10(%ebp),%esi
0x08048b21 do_typedef+17: mov0x8(%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.
pgpXKuJPtriZD.pgp
Description: PGP signature
Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
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: mov0x10(%ebp),%esi
0x08048b21 do_typedef+17: mov0x8(%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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
Le Sun, 23 Oct 2011 12:11:05 +0200, Roman Divacky rdiva...@freebsd.org a écrit : 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. Unless you think that it will be helpful to test with the workaround, I would prefer to test patches from llvm (it takes days to build FreeBSD on a net5501...). This proves it is useful to test with uncommon hardware, and I would like to check the crypto engine, hifn(4) and glxsb(4) built with llvm (that worked fine around january). Thanks a lot, regards. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
Hello, Patrick. You wrote 23 октября 2011 г., 17:38:21: Unless you think that it will be helpful to test with the workaround, I would prefer to test patches from llvm (it takes days to build FreeBSD on a net5501...). Another important case: build on common hardware for such strange systems. My net5501 boots from image built on Intel Q9650-based system (i386, of course). -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
Le Sat, 22 Oct 2011 20:51:29 +0200, Patrick Lamaiziere patf...@davenulle.org a écrit : On my Soekris net5501 (AMD Geode i586 CPU) clang make buildworld fails on an illegal instruction nopw %cs:0x0(%eax,%eax,1). I've found a test program from Roman Divacky to check the CPU as clang (http://lev.vlakno.cz/~rdivacky/Host.cpp) It returns cpu = pentium, looks good. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
