"Core" thread doesn't become active in kernel initialization

[Bob Stewart]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20150702/b27cfeb0/attachment.html>