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