env() function at different places returns different addresses

[jaeyong yoo]

Thanks a lot Norman.
It helped a lot understand how env works.

One more question is that "how do you backtrace init?"
And, by any chance, is there any builtin function that performs backtrace
(like backtrace function of glibc in Linux)?

Best,
Jaeyong

On Sun, Nov 18, 2012 at 3:35 AM, Norman Feske
<norman.feske at ...1...>wrote:

> 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
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20121119/5f43efb7/attachment.html>