This is the mail archive of the ecos-bugs@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug 19970] New: mips back trace incomplete


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

           Summary: mips back trace incomplete
           Product: eCos
           Version: unknown
          Platform: Other
        OS/Version: Other
            Status: RESOLVED
          Severity: normal
          Priority: low
         Component: Other
        AssignedTo: ebachalo at schuilenburg dot org
        ReportedBy: nobody at cygnus dot com
                CC: jifl at ecoscentric dot com


When I set a breakpoint and do a stacktrace (using "bt") on
eCos code built for the mips tx39 simulator, the trace is
incomplete. This applies to both the command-line
tool, and GDBtk. See the example below.

How-To-Repeat:
peshwari:~/ecc/doc/examples$ mips-tx39-elf-gdb -nw twothreads
GNU gdb 4.17-ecos-98r1p5
Copyright 1998 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.  This version of GDB is supported
for customers of Cygnus Solutions.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=mips-tx39-elf"...
(gdb) tsim
Connected to the simulator.
Loading section .rom_vectors, size 0x218 lma 0xbfc00000
Loading section .text, size 0x9710 lma 0xbfc00218
Loading section .rodata, size 0x798 lma 0xbfc09928
Loading section .data, size 0x2678 lma 0xbfc0a0c0
Start address 0xbfc00000
Transfer rate: 408000 bits in <1 sec.
Function "cyg_test_exit" not defined.
(gdb) b Cyg_Thread::exit
Breakpoint 1 at 0xbfc02f48: file /local/disk5/ecc-obj/install/include/cyg/kernel/thread.inl, line 223.
(gdb) run
Starting program: /n/tikka/home/jlarmour/ecc/doc/examples/twothreads 
Entering twothreads' cyg_user_start() function

Breakpoint 1, Cyg_Thread::exit () at /local/disk5/ecc-obj/install/include/cyg/kernel/thread.inl:223
223         return Cyg_Scheduler::get_current_thread();
(gdb) bt
#0  Cyg_Thread::exit () at /local/disk5/ecc-obj/install/include/cyg/kernel/thread.inl:223
#1  0xbfc070fc in __libc__exit (status=0)
    at /home/jlarmour/ecc/ecc/language/c/libc/current/src/stdlib/_exit.cxx:88


It stops here, but it should also have had __libc_exit (there's
a difference), cyg_libc_invoke_main() and
Cyg_Hardware_Thread::thread_entry()

The above trace was one of the example programs that comes
with eCos, called twothreads.

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

[ Time passes... :-) ]

Actually I see this isn't mips-specific. Here's the same for mn10300-elf:

(gdb) b Cyg_Thread::exit
Breakpoint 1 at 0x400016b6: file /home/jlarmour/ecc/ecc/kernel/current/src/common/thread.cxx, line 724.
(gdb) list thread.cxx:710
705
706         CYG_REPORT_RETURN();
707     }
708
709     // -------------------------------------------------------------------------
710     // Exit thread. This puts the thread into EXITED state.
711
712     void
713     Cyg_Thread::exit()
714     {
(gdb) 
715         // The thread should never return from this function.
716
717         Cyg_Thread *self = Cyg_Thread::self();
718
719         Cyg_Scheduler::lock();
720
721         // clear the timer; if there was none, no worries.
722         clear_timer();
723
724         self->state = EXITED;
(gdb) msim
Connected to the simulator.
Loading section .rom_vectors, size 0xc0 lma 0x40000000
Loading section .text, size 0x5c3c lma 0x400000c0
Loading section .rodata, size 0x6bf lma 0x40005cfc
Loading section .data, size 0x1f4 lma 0x400063bc
Start address 0x40000000
Transfer rate: 208248 bits in <1 sec.
Function "cyg_test_exit" not defined.
(gdb) run
Starting program: /home/jlarmour/ecc/doc/examples/twothreads 
Entering twothreads' cyg_user_start() function

Breakpoint 1, Cyg_Thread::exit ()
    at /home/jlarmour/ecc/ecc/kernel/current/src/common/thread.cxx:724
724         self->state = EXITED;
(gdb) bt
#0  Cyg_Thread::exit () at /home/jlarmour/ecc/ecc/kernel/current/src/common/thread.cxx:724
#1  0x400045d1 in __libc__exit (status=0)
    at /home/jlarmour/ecc/ecc/language/c/libc/current/src/stdlib/_exit.cxx:88
#2  0x4000453c in cyg_libc_get_errno_p ()
    at /home/jlarmour/ecc/ecc/language/c/libc/current/src/stdlib/exit.cxx:94

I don't know where it got cyg_libc_get_errno_p() from, but exit.cxx:94 is the
correct line number in the function __libc_exit() (which calls __libc__exit())
for that stack level. Its still missing cyg_libc_invoke_main and
Cyg_HardwareThread::thread_entry() though.

HTH,

Jifl

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

Originator:
Jonathan Larmour

Organization:
cygnus

Audit-Trail:
Responsible-Changed-From-To: alexs->ebachalo 
Responsible-Changed-By: alexs 
Responsible-Changed-When: Tue Apr 27 06:44:26 PDT 1999 
Responsible-Changed-Why:  
Hi Eric 

Another problem thrown out by eCos QA. 

-- Alex

Unformatted:
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:11 BST -------
Tools issue



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]