Debugging without GDB - stack print?

Alexander Tormasov a.tormasov at
Mon Aug 26 16:07:09 CEST 2019

> For 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' ( 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:
/* The main function.  */

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

And it is called from genode _main where, I assume, Genode::Core_env  is initialized?
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 … I add it to the list, and now fight with non-initialized variables.

More information about the users mailing list