This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: (bad) disassemblie
Holger Eitzenberger writes:
> 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.
It's intended. Looks to me like these are offset tables; the repeated fe ff ff
is a clue.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903