This is the mail archive of the
ecos-maintainers@sourceware.org
mailing list for the eCos project.
Re: GCC 4.6 resourcing.
- From: Ilija Kocho <ilijak at siva dot com dot mk>
- To: John Dallaway <john at dallaway dot org dot uk>
- Cc: ecos-maintainers at ecos dot sourceware dot org
- Date: Fri, 27 Jan 2012 15:32:07 +0100
- Subject: Re: GCC 4.6 resourcing.
- References: <4F1EF26A.6010201@siva.com.mk> <4F1F265B.2080700@dallaway.org.uk>
Hi John
On 24.01.2012 22:44, John Dallaway wrote:
Hi Ilija
Does the backtrace for an eCos thread and for HAL startup code work
reliably with GDB 7.3.1? In the past, we have seen issues where the
backtrace code can enter an infinite loop, hence the patch for GDB 6.8.50.x.
Now I have addressed GDB patches too. Here's the outcome:
File: gdb-6.8.50.20080706.patch
frame.c
eCos backtrace hack.
Wasn't applied, /bt/ didn't stop at /thread_entry/. I did apply all
patches to frame.c and now it seems to work properly (Screen captures
are below).
findvar.c
The patches mention phrase "frame" so I assume they are related to
frame.c patches.
I did apply the patches but my assumption may be wrong. Need
confirmation?
valops.c
Same discussion as for findvar.c
infcall.c
Was up to date.
symtab.c
Was up to date.
dwarf2-frame.c
Code has changed, patch is very likely obsolete.
File: gdb-6.8.50.20080706-arm.patch
The subject sources have been significantly reworked. I could identify
that some patches have been applied and some parts reworked beyond
recognition. Very likely that all patches are obsolete.
----- Screen captures [nc_test_slave]
----------------------------------------
-- Before patch: ----
gdb> bt
#0 do_some_random_computation (p=<optimized out>) at
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:684
#1 net_load (who=<optimized out>) at
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:668
#2 0x000033be in Cyg_HardwareThread::thread_entry (thread=0x1fff28d8)
at
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/kernel/current/src/common/thread.cxx:94
#3 0x00003b7a in Cyg_Scheduler::start_cpu () at
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/kernel/current/src/sched/sched.cxx:402
#4 0x000033ac in reschedule () at
/home/vae/Proekti/pd/sem/ecos_kinetis/lwip_test_install/include/cyg/kernel/sched.inl:114
#5 Cyg_Thread::exit () at
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/kernel/current/src/common/thread.cxx:771
#6 0x00000000 in ?? ()
-- After patch: ----
gdb> bt
#0 do_some_random_computation (p=<optimized out>) at
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:684
#1 net_load (who=<optimized out>) at
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/net/lwip_tcpip/current/tests/nc_test_slave.c:668
#2 0x000033be in Cyg_HardwareThread::thread_entry (thread=0x1fff28d8)
at
/home/vae/Proekti/ecos/repo/cvs/current/ecos_kin/packages/kernel/current/src/common/thread.cxx:94
-------------------------------------------------------------------------------
I would suggest something like:
--with-pkgversion='eCos GNU tools 4.6.2-20120124'
Accepted and incorporated.
I have suitably old Linux and Cygwin installations here and can generate
releases based on your patches if you prefer.
I also did some fixes/clean up/branding to GCC and I'm doing the final
tests. I'll take Sergei's suggestion for using Bugzilla obsoleting
feature as VCS, so later evening or during the weekend I am going to put
all patches and scripts in a private maintainer bug - for review as well
as for you to pick them up for building.
Ilija