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.