lkml.org 
[lkml]   [1999]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: alpha copy_to_user (was Re: NFS fails under 2.2.6)
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [from the cache]
©2003-2011 Jasper Spaans