[Bug backtrace/10310] New: (GNU/Linux:GCC:C lang: ARM platform) Core dump backtrace on stripped binaries Halts in 2 levels

[Bug backtrace/10310] New: (GNU/Linux:GCC:C lang: ARM platform) Core dump backtrace on stripped binaries Halts in 2 levels

[informkarthik at gmail dot com]

Backtrace on stripped binaries in ARM platform do not go beyond two levels. gdb
throws 'identical frame' (corrupt stack) message. Noticed that gdb takes the
path of stack unwinding using frame pointer and standard stack frame structure.
How reliable is this?

Steps to reproduce: 
1) Just build using the following compiler options 
-mabi=aapcs-linux -mno-thumb-interwork -fno-strict-aliasing -fno-common -Os
-fno-strict-aliasing -fno-common -marm -mhard-float -mfloat-abi=softfp -mfpu=vfp
-mno-sched-prolog  -march=armv5te -mtune=marvell-f -fno-optimize-sibling-calls
-fno-stack-protector -fno-omit-frame-pointer  -fPIC.
2) send sigsegv or sigabrt to the app.
3) core dumped.
4) arm-none-linux-gnueabi-gdb app core
5) bt gives only two levels of addresses and halts with the message
previous frame identical to this frame (corrupt stack?).
---
Noticed similar output in my x86 setup also.. except that it prints the same
couple of addresses twice before exiting with the 'identical frame' message.

-- 
           Summary: (GNU/Linux:GCC:C lang: ARM platform) Core dump backtrace
                    on stripped binaries Halts in 2 levels
           Product: gdb
           Version: 6.8
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: backtrace
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: informkarthik at gmail dot com
                CC: gdb-prs at sourceware dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=10310

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug backtrace/10310] (GNU/Linux:GCC:C lang: ARM platform) Core dump backtrace on stripped binaries Halts in 2 levels

[informkarthik at gmail dot com]

------- Additional Comments From informkarthik at gmail dot com  2009-06-23 07:03 -------
(In reply to comment #0)
> Backtrace on stripped binaries in ARM platform do not go beyond two levels. gdb
> throws 'identical frame' (corrupt stack) message. Noticed that gdb takes the
> path of stack unwinding using frame pointer and standard stack frame structure.
> How reliable is this?
> 
> Steps to reproduce: 
> 1) Just build using the following compiler options 
> -mabi=aapcs-linux -mno-thumb-interwork -fno-strict-aliasing -fno-common -Os
> -fno-strict-aliasing -fno-common -marm -mhard-float -mfloat-abi=softfp -mfpu=vfp
> -mno-sched-prolog  -march=armv5te -mtune=marvell-f -fno-optimize-sibling-calls
> -fno-stack-protector -fno-omit-frame-pointer  -fPIC.
> 2) send sigsegv or sigabrt to the app.
> 3) core dumped.
> 4) arm-none-linux-gnueabi-gdb app core
> 5) bt gives only two levels of addresses and halts with the message
> previous frame identical to this frame (corrupt stack?).
> ---
> Noticed similar output in my x86 setup also.. except that it prints the same
> couple of addresses twice before exiting with the 'identical frame' message.
I see it even in unstripped binaries right now.. it looks like this
(gdb) bt
#0  0x00008344 in temp3 ()
#1  0x00008358 in temp2 ()
#2  0x00008358 in temp2 ()
#3  0x00008370 in temp1 ()
#4  0x000083a0 in main ()

Look at temp2. Note all the funtions just call the next function and do nothing
else. temp3 has while(1) in it so that i can send a signal and get core dump.
The stack looks like the following:
(gdb) x/16w $sp-12
0x56d7dd34:     0x00008294      0x00000000      0x00000000      0x56d7dd4c
0x56d7dd44:     0x00008358      0x56d7dd54      0x00008370      0x56d7dd64
0x56d7dd54:     0x000083a0      0x00000005      0x40024e00      0x00000000
0x56d7dd64:     0x4003aff4      0x40153000      0x56d7deb4      0x00000001



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1


http://sourceware.org/bugzilla/show_bug.cgi?id=10310

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug backtrace/10310] (GNU/Linux:GCC:C lang: ARM platform) Core dump backtrace on stripped binaries Halts in 2 levels

[informkarthik at gmail dot com]

------- Additional Comments From informkarthik at gmail dot com  2009-06-29 09:43 -------
We figured out that this is specific to our target. There were two things that
we had to do.
1) Enable apcs-frame option for gcc.
2) Change the program counter correction to 12 (instead of 8). This is machine
specific.
--- gdb/arm-tdep.c.orig 2009-06-29 15:14:52.000000000 +0530
+++ gdb/arm-tdep.c      2009-06-29 14:46:41.000000000 +0530
@@ -1366,7 +1366,7 @@
       else
         {
           prologue_start = gdbarch_addr_bits_remove
-                            (gdbarch, return_value) - 8;
+                            (gdbarch, return_value) - 12;
           prologue_end = prologue_start + 64;  /* See above.  */
         }
     }

3) I think we need a comment in arm_scan_prologue, that one needs correction of
12 in some architectures for stack unwinding to work. Do we have any compiler
flags that we can use to incorporate this as a feature that the user can set
while compiling?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=10310

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.