[RFC]: patch #3 for Sun C compiled target programs

[Michael Mueller]

Backtrace for Sun C -O compiled programs doesn't work (64 bit only?)

I verified against target programs compiled with

   Sun WorkShop 6 update 2 C 5.3 2001/05/15 (64 bit)
   Sun WorkShop 6 2000/04/07 C 5.1 (64 bit)

No problems found with:

   Sun C 5.5 2003/03/12
   Forte Developer 7 C 5.4 2002/03/09
   gcc 3.4.0


compile command
   cc -xarch=v9 -O p5.c -o p5

Test source file:

   #include <stdio.h>

   void fun(int k)
     {
     int a, b;

     printf("fun %d %d\n", a, b);
     a = 10;
     b = 20;
     a = (a + b) / 2;
     printf("fun %d %d\n", a, b);
     }

   void main()
     {
     fun(10);
     printf("finished\n");
     }

gdb output

GNU gdb 2004-06-17-cvs
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.8"...(no debugging 
symbols found)
...
(gdb) b fun
Breakpoint 1 at 0x1000009a8
(gdb) run
Starting program: /export/home/michaelm/gdb/gdb-6.1.patch/tst/p5.O.64.51
(no debugging symbols found)...(no debugging symbols found)...(no 
debugging symb
ols found)...
Breakpoint 1, 0x00000001000009a8 in fun ()
(gdb) x/10i fun
0x1000009a8 <fun>:      sethi  %hi(0), %g2
0x1000009ac <fun+4>:    sethi  %hi(0x800), %g3
0x1000009b0 <fun+8>:    or  %g2, 1, %g2
0x1000009b4 <fun+12>:   or  %g3, 0x340, %g3
0x1000009b8 <fun+16>:   sllx  %g2, 0x20, %g2
0x1000009bc <fun+20>:   save  %sp, -192, %sp
0x1000009c0 <fun+24>:   or  %g3, %g2, %o0
0x1000009c4 <fun+28>:   ld  [ %fp + 0x7f7 ], %g2
0x1000009c8 <fun+32>:   mov  0xf, %i1
0x1000009cc <fun+36>:   sra  %g2, 0, %o1
(gdb) bt
#0  0x00000001000009a8 in fun ()
#1  0x0000000100000a24 in main ()
(gdb) b *0x1000009c0
Breakpoint 2 at 0x1000009c0
(gdb) c
Continuing.

Breakpoint 2, 0x00000001000009c0 in fun ()
(gdb) bt
#0  0x00000001000009c0 in fun ()
#1  0x0000000000000008 in ?? ()
Previous frame identical to this frame (corrupt stack?)


=======================================================================

This is caused by function sparc_analyze_prologue in sparc-tdep.c which 
fails to find the SAVE instruction in the debugged function's prolog 
code. The reason is that sparc_analyze_prologue has very precise 
expectations about how the prolog code should be structured and some 
compiler versions break that. I changed it to be more tolerant.

I search a maximum of 32 instructions (hope that this is enough) until I 
find a 'save' or some kind of jump or return instruction.

For opcode details see "The SPARC Architecture Manual".

2004-06-22  Michael Mueller  <m.mueller99@kay-mueller.de>
     * sparc-tdep.c: make prolog analysis code more tolerant



-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: sparc-tdep.patch
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20040622/198efa8a/attachment.ksh>