Re: 2.5.63 accesses below %esp (was: Re: ntfs OOPS (2.5.63))

[Keith Owens]

On Mon, 17 Mar 2003 17:43:21 -0400, 
Horst von Brand <[e-mail]> wrote:
>Denis Vlasenko <[e-mail]> said:
>> How come? If I started to decode at EIP-n and got a sequence of
>> instructions at EIP-n, EIP-n+k1, EIP-n+k2, EIP-n+k3..., EIP,
>> instructions prior to EIP can be wrong. Instruction at EIP
>> and all subsequent ones ought to be right.
>
>Iff you exactly hit EIP that way (sure, should check). But wrong previous
>instructions _will_ confuse people or start them on all kind of wild goose
>chases. Too much work for a dubious gain.

At the risk of stating the obvious: the only program that cares about
the 'Code:' line is ksymoops.  It already handles code around the EIP
by looking for a byte enclosed in <> and assuming that byte is at EIP.
ksymoops can happily decode around the failing instruction and does so
for most architectures with fixed length instructions.

I can change ksymoops to add a special case for architectures with
variable length instructions - i386, s390 and their 64 bit equivalents,
are there any others?  For variable length instructions, ksymoops will
extract the bytes up to but not including eip, decode and print them
with a warning

  This architecture has variable length instructions, decoding before eip is
  unreliable, take these instructions with a pinch of salt.

Then the code from eip onwards will be decoded as normal, with the
heading 'This code should be reliable'.  If a kernel with variable
length instructions prints 'Code:' with a byte enclosed in <> then you
get two decodes with suitable warning messages.  No <> in the code line
means no change from current decode state, everybody is happy.