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    [W:0.021 / U:0.252 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site