env() function at different places returns different addresses

[Norman Feske]

Hello Jaeyong,

your observations are actually plausible. Let me shed some light on both
of them.

> I'm trying to understand how env() and env()->parent() work from the source
> code.
> First, I find the body of env function located at:
>     genode/base/src/base/env/env.cc
> 
> and looks like this:
>     namespace Genode {
>         Env *env()
>         {
>             static Genode::Platform_env _env;
>             return &_env;
>         }
>     }
> 
> env() function looks like, at namespace Genode, it returns the pointer of
> singleton object _env (static Genode::Platform_env _env).
> But, when I call env() at different places, it returns different addresses.
> 
> For instance,
>    - at genode/base/src/core/main.cc
>    - at dde_linux/src/drivers/usb/nic/nic.cc,
> env() function returns different addresses like the following
>    - at genode/base/src/core/main.cc, it returns 801f01a0
>    - at dde_linux/src/drivers/usb/nic/nic.cc, it returns 10b716c.

The 'env()' function is part of the env library, which is linked to each
Genode program. For each executable, the linker decides where in the
virtual address space of the program the symbols of the library go. In
your case, you are looking at two different programs (core and usb_drv).
The address space layout of both programs is different. That includes
the layout of the respective BSS segments. For this reason, each program
returns a different address. When calling 'env()' from different
portions of the same program, the returned addresses will be the same.

> And, one more thing: I was trying to print some debug message at Env *env()
> function like the following.
> 
>         Env *env()
>         {
>             static Genode::Platform_env _env;
>             PDBG("Genode::env() function called");   // my debug message
> 
>             return &_env;
>         }
> 
> And, when I run the genode, it always halt at core and child init is not
> running.
> Do you have any clues?

The system does actually not halt at core but right at the start of the
init process. By inserting the 'PDBG' statement, you just created a
cyclic dependency within init. The 'PDBG' function uses the core's LOG
service to print the message. Hence, init needs to create a LOG session,
which is done by calling 'Genode::env()->parent()->session(...)'. Hence,
when 'env()' is called the first time (apparently when init tries to
obtain its config), the function tries to indirectly call 'env()'. To
illustrate the situation, the backtrace of init looks as follows:

  main                        init/main.cc:135
  Genode::config              os/config.h:90
  Genode::Config::Config      os/config.h:46
  Rom_connection              rom_session/connection.h:55
  _create_session             rom_session/connection.h:36
  Genode::Connection::session base/connection.h:93
  Genode::env                 env.cc:31
  Genode::printf              log_console.cc:141
  Genode::vprintf             log_console.cc:149
  stdout_log_console          log_console.cc:115
  Log_console                 log_console.cc:68
  Log_connection              log_session/connection.h:27
  Genode::Connection::session base/connection.h:93
  Genode::env                 env.cc:31
  Genode::printf              log_console.cc:141
  Genode::vprintf             log_console.cc:149
  stdout_log_console          log_console.cc:115

At the second recursion level, the static constructor of 'Platform_env'
is already in locked state ('__cxa_guard_acquire' was called at the
first call of 'env()'). Hence, the programs tries to obtain the same
lock twice and deadlocks.

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth