Thank you for the suggestions, Martin.
Stack corruption does not appear to be the issue: (a)Your PINF in [1] yields a run-time error -- "SP <warning: unsupported format string argument>p". (Not sure why that would be.) (b) Replacing %p with 0x%x and applying the appropriate cast, results in PINF showing "SP 0x810893f0". (c) The kernel_stack$ symbol is set at "81079440 B kernel_stack". (d )KERNEL_STACK_SIZE = 64 * 1024. So the stack pointer is appropriately near the top of the stack, assuming it's growing from top to bottom.
Your suggestion, [4] failed to compile with the following error output: "//Work/Genode/genode-15.05/repos/base/src/base/include/unmanaged_singleton.h: In instantiation of ‘T* unmanaged_singleton(ARGS ...) [with T = Kernel::Core_thread; int ALIGNMENT = 4; ARGS = {}]’:// ///Work/Genode/genode-15.05/repos/base-hw/src/core/kernel/thread.cc:805:45: required from here// ///Work/Genode/genode-15.05/repos/base-hw/src/core/kernel/thread.cc:771:1: error: ‘Kernel::Core_thread::Core_thread()’ is private// // Core_thread::Core_thread()// // ^// //In file included from /Work/Genode/genode-15.05/repos/base-hw/src/core/kernel/thread.cc:17:0:// ///Work/Genode/genode-15.05/repos/base/src/base/include/unmanaged_singleton.h:69:3: error: within this context// // new (&object_space) T(args...);// // ^/" Based on Stefan's suggestion however, the CXA guards appear to be working correctly.
I'll look into your thought about the cpu_id, once I understand its purpose and use.
I should also note that the thread.cc I'm using contains two additional methods and associated call case statements I ported from my modified kernel from an AM335x implementation. Those core-based kernel calls are necessary in both the 4371 and 335x to allow writing to control subsystem registers in these platforms. I don't believe these changes have anything to do with the issue, but it is a difference.
Thanks, Bob On 07/02/2015 05:46 AM, Martin Stein wrote:
Hi Bob,
On 01.07.2015 21:42, Bob Stewart wrote:
Once the Core_thread singleton is created the last printf output that appears is one I inserted after the call to to _become_active() in the constructor. A printf inserted into the singleton method after the Core_thread creation never shows up on the console. The initialization never completes.
This might be caused by a stack corruption. I would check whether the stack pointer (insert [1] after _become_active()) is inside the kernel_stack array (constraints via [2]). If the AM437x's hardware CPU-ID of your CPU is not 0, this might be a problem as this value is used to index CPU local data like the kernel stack. Another problem might be the CXA guard stuff that Stefan mentioned. Additional to Stefans suggestions you can try to prevent CXA guards by replacing [3] with [4]. This way, you can easily validate the assumption before digging deeper into it.
Cheers, Martin
[1] int i = 0; PINF("SP %p", &i);
[2] /usr/local/genode-gcc/bin/genode-arm-nm bin/core | grep "kernel_stack$" grep -r "KERNEL_STACK_SIZE =" base-hw/
[3] Thread & Core_thread::singleton() { static Core_thread ct; return ct; }
[4] #include <unmanaged_singleton.h> Thread & Core_thread::singleton() { return *unmanaged_singleton<Core_thread>(); }
Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main