[Bug 19981] New: [stub/ARM] Backtrace from inactive thread is wrong

[bugzilla-daemon at ecoscentric dot com]

http://bugs.ecos.sourceware.org/show_bug.cgi?id=19981

           Summary: [stub/ARM] Backtrace from inactive thread is wrong
           Product: eCos
           Version: unknown
          Platform: Other
        OS/Version: ARM
            Status: UNCONFIRMED
          Severity: major
          Priority: low
         Component: Debugging
        AssignedTo: gary at mlbassoc dot com
        ReportedBy: nobody at cygnus dot com


Doing a backtrace from an inactive thread in the twotreads example results in this:

#0  0x1419c in hal_thread_switch_context ()
#1  0x11964 in Cyg_Scheduler::unlock_inner () at //C/CYGNUS~1/eCos/packages/kernel/v1_2_1/src/sched/sched.cxx:142
#2  0x11940 in Cyg_Scheduler::unlock_inner () at //C/CYGNUS~1/eCos/packages/kernel/v1_2_1/src/sched/sched.cxx:127
#3  0x10f6c in Cyg_Thread::delay (this=0x206cc, delay=247) at /c/tmp/aa/install/include/cyg/kernel/sched.inl:90
#4  0x106d8 in cyg_thread_delay (delay=442209832928984) at //C/CYGNUS~1/eCos/packages/kernel/v1_2_1/src/common/kapi.cxx:231
#5  0x205fc in stack ()

While I would have expected this particular thread (one of the primary test threads) to end in:

#5  simple_program (data=1) at twothreads.c:51
#6  0x10848 in Cyg_HardwareThread::thread_entry (thread=0x20630) at //C/CYGNUS~1/eCos/packages/kernel/v1_2_1/s

or similar. I.e. the top of the call chain should be the test function and then the thread_entry code.

How-To-Repeat:
Configure the kernel with stubs and GDB BREAK support. Build the example twothreads.

Download to (AEB) target, set a breakpoint on twothreads.c:51 ( delay = 200 + (rand() % 50);). 

Run.

Continue a couple of times so you can see which thread IDs are assigned to the two threads running this function.

Change to other thread running this function when the breakpoint is hit  next time.

Do the backtrace.


---------------------------------------------------------------------------

Originator:
Jesper Skov

Organization:
CS

Audit-Trail:
Responsible-Changed-From-To: alexs->gthomas 
Responsible-Changed-By: alexs 
Responsible-Changed-When: Wed Apr 28 01:59:04 PDT 1999 
Responsible-Changed-Why:  
Previous communication: 

Gary Thomas wrote: 
On 28-Apr-99 Jesper Skov wrote: 
State-Changed-From-To: open-analyzed 
State-Changed-By: gthomas 
State-Changed-When: Mon Sep 20 05:55:23 PDT 1999 
State-Changed-Why:  
I don't think this problem is limited to the backtrace of an idle thread. 
The ARM GDB code doesn't always work properly when generating a backtrace. 

This patch [I think] fixes the problem. 

Index: arm-tdep.c 
=================================================================== 
RCS file: /cvs/cvsfiles/devo/gdb/arm-tdep.c,v 
retrieving revision 1.27.12.1.8.3 
diff -u -5 -p -r1.27.12.1.8.3 arm-tdep.c 
--- arm-tdep.c  1999/07/31 00:59:26     1.27.12.1.8.3 
+++ arm-tdep.c  1999/09/20 12:51:18 
@@ -532,10 +532,12 @@ arm_scan_prologue (fi) 

if (sal.line == 0)               /* no line info, use current PC */ 
prologue_end = fi->pc; 
else if (sal.end < prologue_end) /* next line begins after fn end */ 
prologue_end = sal.end;         /* (probably means no prologue)  */ 
+      // Include current instruction in scan 
+      prologue_end += 4; 
} 
else 
{ 
/* Get address of the stmfd in the prologue of the callee; the saved 
PC is the address of the stmfd + 8.  */ 



From: "Alex Schuilenburg" <alexs at cygnus dot co dot uk>
To: "Bugs" <bugs at cygnus dot com>
Cc:  Subject: Re: ecc/19981: [stub/ARM] Backtrace from inactive thread is wrong
Date: Mon, 11 Oct 1999 17:39:43 +0100

 Gary reports that this patch is not sufficient, and that James Ingham
 may have a more complete patch.
 
 This issue remains open :-(
 -- Alex
 
Responsible-Changed-From-To: gthomas->fnasser 
Responsible-Changed-By: cgf 
Responsible-Changed-When: Mon Oct 25 10:36:22 PDT 1999 
Responsible-Changed-Why:  
GDB engineer 

Responsible-Changed-From-To: fnasser->kingdon
Responsible-Changed-By: cgf
Responsible-Changed-When: Mon Jan 24 13:12:34 PST 2000
Responsible-Changed-Why: 
New support engineer.


Category-Changed-From-To: ->ecc
Category-Changed-By: cgf
Category-Changed-When: Mon Jan 24 13:12:34 PST 2000
Category-Changed-Why:

Unformatted:
>>>>>> "Alex" == Alex Schuilenburg <alexs at cygnus dot co dot uk> writes: 
>  
> Alex> Hi Jesper Is this a eCos or GDB issue?  Should I assigne to 
> Alex> gthomas or ebachalo? 
>  
> I think it belongs with Gary. It might be a generic stub problem, but 
> I doubt it. It may be that one can only go back so many frames on the 
> ARM!?!?  

More likely the stack is not set up properly for the initial frame.  I'll 
look into it. 

>  
> Mind you, I saw the same on MN10300/CygMon, so it might be GDB... Or a 
> similar problem with MN10300 capabilities. 
>  
> Jesper 
>  


Originator:  

page: www.cygnus.com/product/ecc-pr.html

Send_PR_form: Sent_from_www.cygnus.com

------- Additional Comments From alexs at ecoscentric dot com  2003-24-04 17:24 BST -------
Old issue probably long since fixed



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.