Debugging without GDB - stack print?

[Alexander Tormasov]

> 
> For ld.lib.so and test-go, the address corresponds exactly. So, the page
> fault appears to occur at
> 
> Ram_dataspace_capability const ds_cap = ram->alloc(ds_size);
> 
> Maybe 'env_stack_area_ram_allocator' (thread.cc:51) has not been
> initialized?
> 

Yes, this is the core of the problem. Seems that function Genode::Core_env 
   bool _init_stack_area() { init_stack_area(); return true; }
Does no called.
From core_env.h

How this could happened? 
I have for go own runtime function main() in normal C style:
Like
...
/* The main function.  */

int
main (int argc, char **argv)
{
runtime_isarchive = false;
...

And it is called from genode _main where, I assume, Genode::Core_env  is initialized?
genode/repos/base/src/lib/startup/_main.cc:
void Component::construct(Genode::Env &env) __attribute__((weak));
void Component::construct(Genode::Env &env)
{
   /* call real main function */
   exit_status = main(genode_argc, genode_argv, genode_envp);

May be I need to call something else before my main?

> 
>> I wonder if your test application really needs to be started with Noux though. If it doesn't need fork() or execve(), it would
>> probably be easier not to use Noux.
>> 
>> I suppose that some of emulation of generic libc implemented inside noux (like used inside libgo getpid/pthread/etc) - and this is the main reason why I try to link it.
>> May be I am wrong ?
> 
> 
> I would try a simple "hello world" application without Noux first and
> hope that libgo does not need fork, execve, wait or getpid for that.
> pthreads should also work without Noux.

This is exactly what I am doing. I found that I can’t link test_go app without libc_noux.lib.so … I add it to the list, and now fight with non-initialized variables.