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