On Thu, 22 Apr 1999 08:55:00 +0100 (GMT), 
Tim Waugh <tim@cyberelk.demon.co.uk> wrote:
>> > >>EIP: fffffc000034b138 <filldir+e8/148>
>> > Code:  fffffc000034b12c <filldir+dc/148>               0000000000000000 <_EIP>:
>> > Code:  fffffc000034b12c <filldir+dc/148>                  0:	44 22 00 01 	call_pal	0x1002244
>
>Actually, the other thing I should have mentioned is that this disassembly
>is wrong.  It should read (i.e. objdump -d vmlinux says):
>
>fffffc000034ae3c:       01 00 22 44     and     t0,t1,t0
>
>Evidently ksymoops needs a bit of looking at.

Endianess ambiguity.  Alpha dumps code as words, ksymoops reads text
from the log as bytes.  The Code: line was

Code: 44220001  f4200003  46520400 <a77d9c38> 6b9b4a40  a44803a8  42425401  42c10403  40603401

Reading as bytes, that first word ended up as 0x44220001 instead of the
original 0x01002244.  Yes, ksymoops could "know" the endianess of the
machine it was running on.  But that messes up users doing cross system
Oops debugging, e.g. running an i370 dump through ksymoops on i386.  I
wish *all* architectures did a consistent dump of the code line, one
byte at a time with space between them, it is the only display format
that has no endianess ambiguity.

Until that blissful state occurs, Alpha users need to specify "-c 4"
when running ksymoops.  That tells ksymoops that the input is 4 byte
chunks that need to be byte swapped.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/