Messages in this thread | | | From | Keith Owens <> | Subject | Re: 2.5.63 accesses below %esp (was: Re: ntfs OOPS (2.5.63)) | Date | Tue, 18 Mar 2003 14:28:04 +1100 |
| |
On Mon, 17 Mar 2003 17:43:21 -0400, Horst von Brand <vonbrand@inf.utfsm.cl> wrote: >Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> 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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |