This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: (bad) disassemblie
Andrew Haley <aph@redhat.com> writes:
> > while hunting down a strange Linux kernel bug I saw this in the
> > disassemblie:
> >
> > <radix_tree_insert>:
> > ...
> > c01ccf21: 0f 84 bd fe ff ff je c01ccde4 <radix_tree_insert+0x64>
> > c01ccf27: 0f 0b ud2a
> > c01ccf29: 1b 01 sbb (%ecx),%eax
> > c01ccf2b: ab stos %eax,%es:(%edi)
> > c01ccf2c: 78 31 js c01ccf5f <radix_tree_insert+0x1df>
> > c01ccf2e: c0 e9 b0 shr $0xb0,%cl
> > c01ccf31: fe (bad) # <<< here
> > c01ccf32: ff (bad)
> > c01ccf33: ff c6 inc %esi
> > c01ccf35: 04 0a add $0xa,%al
> > c01ccf37: 01 e9 add %ebp,%ecx
> >
> > WRT to the two (bad) opcodes, should I start to worry?
>
> Looks like data to me, not code.
Do you think this is intended?
According to the Intel x86 documentation the 'count' argument of the
'shr' instruction is mapped down to 5 bits (0 - 31), so that seems to be
fine.