* (bad) disassemblie
@ 2007-12-17 10:53 Holger Eitzenberger
2007-12-17 12:00 ` Andrew Haley
2007-12-17 19:02 ` Scott Moore
0 siblings, 2 replies; 5+ messages in thread
From: Holger Eitzenberger @ 2007-12-17 10:53 UTC (permalink / raw)
To: gcc-help
gcc-4.1.2 (vanilla)
Linux kernel 2.6.16.y
binutils 2.16.91.0.5 (SLES10)
Hi list,
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?
/holger
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: (bad) disassemblie
2007-12-17 10:53 (bad) disassemblie Holger Eitzenberger
@ 2007-12-17 12:00 ` Andrew Haley
2007-12-17 14:51 ` Holger Eitzenberger
2007-12-17 19:02 ` Scott Moore
1 sibling, 1 reply; 5+ messages in thread
From: Andrew Haley @ 2007-12-17 12:00 UTC (permalink / raw)
To: Holger Eitzenberger; +Cc: gcc-help
Holger Eitzenberger writes:
> gcc-4.1.2 (vanilla)
> Linux kernel 2.6.16.y
> binutils 2.16.91.0.5 (SLES10)
>
> Hi list,
>
> 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.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: (bad) disassemblie
2007-12-17 12:00 ` Andrew Haley
@ 2007-12-17 14:51 ` Holger Eitzenberger
2007-12-17 15:49 ` Andrew Haley
0 siblings, 1 reply; 5+ messages in thread
From: Holger Eitzenberger @ 2007-12-17 14:51 UTC (permalink / raw)
To: Andrew Haley; +Cc: gcc-help
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: (bad) disassemblie
2007-12-17 14:51 ` Holger Eitzenberger
@ 2007-12-17 15:49 ` Andrew Haley
0 siblings, 0 replies; 5+ messages in thread
From: Andrew Haley @ 2007-12-17 15:49 UTC (permalink / raw)
To: Holger Eitzenberger; +Cc: gcc-help
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: (bad) disassemblie
2007-12-17 10:53 (bad) disassemblie Holger Eitzenberger
2007-12-17 12:00 ` Andrew Haley
@ 2007-12-17 19:02 ` Scott Moore
1 sibling, 0 replies; 5+ messages in thread
From: Scott Moore @ 2007-12-17 19:02 UTC (permalink / raw)
To: Holger Eitzenberger, gcc-help
Hi list,
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>
It's jumping over the data here^^^
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?
/holger
Looks to me like everything from c01ccf2e to c01ccf5f could be data.
The lesson here is look at the .S assembly files, not your disassembies.
Scott
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2007-12-17 19:02 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-12-17 10:53 (bad) disassemblie Holger Eitzenberger
2007-12-17 12:00 ` Andrew Haley
2007-12-17 14:51 ` Holger Eitzenberger
2007-12-17 15:49 ` Andrew Haley
2007-12-17 19:02 ` Scott Moore
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).