Problems with gdb on SuSE 7.3 sparc machine.

Jeff Graham <[email protected]>
Newsgroups gmane.linux.suse.sparc
Message-ID <[email protected]>
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 <[email protected]>  
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: [email protected]
For additional commands, e-mail: [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.