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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:19 UTC