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