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