[suse-sparc] Problems with gdb on SuSE 7.3 sparc machine.

From: Jeff Graham (suse_at_demit.net)
Date: Wed May 08 2002 - 01:09:13 CEST

  • Next message: Solarisexpert.com: "[suse-sparc] RE: Cloning boot disk"

    Date: Tue, 7 May 2002 16:09:13 -0700
    From: Jeff Graham <suse@demit.net>
    Message-ID: <20020507160913.A73464@anarchy.com>
    Subject: [suse-sparc] Problems with gdb on SuSE 7.3 sparc machine.
    

    Hi I am looking for a fix for a problem we are seeing with SuSE 7.3
    sparc. It occurs on the package that comes with SuSE 7.3 iso images
    (4.18)

    I am attaching a sample source file for recreating the problem. I am
    looking for a fix or work around.

    Below, please see a description of the issue, followed by a sample
    program that will demonstrate the bug.

    Here is the text describing the bug (this is also included in the source

    comments):

    Sample program that shows a bug in gdb. The bug is described from a C
    language perspective as well as from a machine language perspective (the
    latter will help the implementor in isolating the cause of the problem)

    The bug in terms of "C":
    Single stepping through this statement (val1 ==
    0x00000200):

          byte = (val1 & 0x00007f00) >> 8;

    causes byte to be assigned the incorrect value of 0x00 when it should
    have been assigned 0x02.

    The bug in terms of Sparc machine code:
    Single stepping on a Shift Right Logical overwrites %o0 -
    the "srl %o0, 8, %o1" instruction changes the value of %o0
    (to 0) during srl execution, resulting in both %o0 and %o1
    to contain 0 (they should contain 0x0200 and 0x2 respectively).

    Conditions for the bug:

    1) this behavior is manifested only when single stepping through the
    line described (step or next)

    2) this only happens if the value being shifted is 0x0200!!! Try any
    other value (single step ok) and it works..

    compiled with "gcc -g gbug.c"

    gbug.c
    -------------------------

    // Sample program that shows a bug in gdb. The bug is described
    // from a C language perspective as well as from a machine
    // language perspective (the latter will help the implementor
    // in isolating the cause of the problem)
    //
    // The bug in terms of "C"
    // Single stepping through this statement:
    // byte = (val1 & 0x00007f00) >> 8;
    // causes byte to be assigned the incorrect value of 0x00 when it
    // should have been assigned 0x02.
    //
    // The bug in terms of sparc machine code:
    // Single stepping on a Shift Right Logical overwrites %o0 -
    // the "srl %o0, 8, %o1" instruction changes the value of %o0
    // to 0 during srl execution, resulting in both %o0 and %o1
    // to contain 0 (they should contain 0x0200 and 0x2 respectively).
    //
    // Conditions for the bug:
    //
    // 1) this behavior is manifested only when single stepping
    // thru the program (step or next)
    //
    // 2) this only happens if the value being shifted is 0x0200!!!
    // Try any other value (single step ok) and it works..
    //
    // compiled with "gcc -g gbug.c"
    //

    #include "stdio.h"

    int main(int argc, char* argv[])
    {
        unsigned long val1 = 0x00000200; // we want to extract 02 -
    fails
        unsigned long val2 = 0x00001200; // we want to extract 12 -
    works!
        unsigned char byte;

        byte = 0;

        /*************start-line-that-fails-if-single-stepping**********/
        byte = (val1 & 0x00007f00) >> 8;
        /***************end-line-that-fails-if-single-stepping*********/

        printf("byte = %02x\n", byte);

        byte = (val2 & 0x00007f00) >> 8;
        printf("byte = %02x\n", byte);

        return 0;
    }

    -- 
    Jeff Graham <suse@demit.net>  
    GnuPG 1.0.6 Public key #9373D50B (0x9373D50B) certserver.pgp.com
    Key fingerprint = 13FA F174 5F18 F3A8 1EFE  6930 B5FE 45BA 9373 D50B
    

    -- To unsubscribe, e-mail: suse-sparc-unsubscribe@suse.com For additional commands, e-mail: suse-sparc-help@suse.com



    This archive was generated by hypermail 2.1.0 : Wed May 08 2002 - 01:09:25 CEST