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

[Bob Stewart]

Thanks for the quick reply Martin.

Regarding possible issues with CXA guards, I did change the constructor 
of Core_thread to be public and applied your [4] modification. That did 
allow allow the kernel initialization to complete and I got the "kernel 
initialized" message on the console. Now I need to study the guard code 
to see what is going on.

I'll take a look at Console::vprintf to see if I can find the reason I 
get that run-time error on the %p format variable.

My additions to thread.cc simply write a passed value to a register 
pointer which is also a passed argument. But I'll take them out if I 
can't solve the current issue.

My only method of debugging is via printf. After I'm through with this 
issue I think I'll take a look at CoreSight and see what's involved in 
creating a debugger using its trace facilities.

Thanks,
         Bob

On 07/03/2015 06:06 AM, Martin Stein wrote:
> Hi Bob,
>
> On 02.07.2015 21:36, Bob Stewart wrote:
>> (a)Your PINF in [1] yields a run-time error -- "SP <warning: unsupported
>> format string argument>p". (Not sure why that would be.)
> That is indeed strange. I can't reproduce this output with the current
> master branch and the supported platforms. Instead of the warning case,
> the switch(cmd.type) statement in [1] should end up in 'case
> Format_command::PTR'. If you want to dig deeper into that, I would use
> the _out_string method inside the switch statement to find out what's
> going on.
>
>> (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.
> That's right. However, the stack data may still be corrupted by some
> code that uses a broken pointer. That would be hard to debug. A debugger
> that supports watchpoints would be helpful but as you likely would have
> used single stepping in this case, I assume that you don't have such an
> interface. However, before investigating more into that, I would check
> whether the return pointers are correct at the very end of
> Core_thread::Core_thread() respectively __cxa_guard_release by using
> __builtin_return_address(0).
>
>> 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//
> Oh sorry, I didn't consider that the constructor is private. But after
> making it public in [2] the problem is solved and the patch works also
> at runtime.
>
>> I'll look into your thought about the cpu_id, once I understand its
>> purpose and use.
> This was a misconception of mine. I thought that the almost complete SMP
> support for Cortex A9 has already made its way to master. But as this is
> not the case, Cpu::executing_id() always returns 0 independently from
> any hardware. Additionally, if the CPU ID wouldn't be correct, the stack
> pointer would be broken as well as the initialization would have chosen
> the wrong item of the kernel_stack array.
>
>> 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.
> As long as they do not introduce additional data members to
> Kernel::Thread, this should indeed make no difference, especially at
> that early stage where such methods are not called yet. However, just to
> be sure, you may also remove these modifications for now.
>
> Cheers,
> Martin
>
> [1] base/src/base/console/console.cc - void Console::vprintf
> [2] base-hw/src/core/include/kernel/thread.h - class Kernel::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
>