public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug backtrace/10310] New: (GNU/Linux:GCC:C lang: ARM platform) Core dump backtrace on stripped binaries Halts in 2 levels
@ 2009-06-22 17:28 informkarthik at gmail dot com
2009-06-23 7:03 ` [Bug backtrace/10310] " informkarthik at gmail dot com
2009-06-29 9:43 ` informkarthik at gmail dot com
0 siblings, 2 replies; 3+ messages in thread
From: informkarthik at gmail dot com @ 2009-06-22 17:28 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug backtrace/10310] (GNU/Linux:GCC:C lang: ARM platform) Core dump backtrace on stripped binaries Halts in 2 levels
2009-06-22 17:28 [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
@ 2009-06-23 7:03 ` informkarthik at gmail dot com
2009-06-29 9:43 ` informkarthik at gmail dot com
1 sibling, 0 replies; 3+ messages in thread
From: informkarthik at gmail dot com @ 2009-06-23 7:03 UTC (permalink / raw)
To: gdb-prs
------- 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug backtrace/10310] (GNU/Linux:GCC:C lang: ARM platform) Core dump backtrace on stripped binaries Halts in 2 levels
2009-06-22 17:28 [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
2009-06-23 7:03 ` [Bug backtrace/10310] " informkarthik at gmail dot com
@ 2009-06-29 9:43 ` informkarthik at gmail dot com
1 sibling, 0 replies; 3+ messages in thread
From: informkarthik at gmail dot com @ 2009-06-29 9:43 UTC (permalink / raw)
To: gdb-prs
------- 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-06-29 9:43 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-22 17:28 [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
2009-06-23 7:03 ` [Bug backtrace/10310] " informkarthik at gmail dot com
2009-06-29 9:43 ` informkarthik at gmail dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).