Hi Denis,
On 08/02/2016 11:18 AM, Denis Huber wrote:
Dear Genode Community,
perhaps my questions were too specific. Instead of answering them, I want to summarize them into one general question:
What is the general approach to read the address space content of a component within a custom service located in core?
(For identifying a component I can use its label.)
Your mail hit the list exactly when I finished writing a response to your last question ;-).
To sum it up again, the general approach would be to not read the address space content in core, but in an extra component. I only wanted to add: our GDB port is a good example for the same practice. It intercepts several core services to know of all threads in a component, and to inspect its address space.
Best regards Stefan
Thanks in advance Denis
On 29.07.2016 12:15, Denis Huber wrote:
Dear Genode community,
I want to implement a new service (class Cr_session) residing in core which provides an Rpc method to checkpoint the state of a specific component (given its label string). I am using Genode 16.05 and the foc kernel (pbxa9 build). The first step is to store the content of the address space of the compoent. My approach is the following:
- First a test component is created which shall be checkpointed. The
component counts an integer every second.
In base/src/test/cr_service/counter/main.cc (newly created file): !void Component::construct(Genode::Env &env) !{ ! unsigned int n = 0; ! Timer::Connection timer(env); ! ! while(1) ! { ! Genode::log(n); ! n++; ! timer.msleep(1000); ! } !}
- To realize the CR service in core, I want to find the specific PD
session of the test component. Therefore a separate Sliced_heap exclusively for Pd_session_component objects is created in core's main function.
In base/src/core/main.cc: !static Sliced_heap pd_sliced_heap(env()->ram_session(), env()->rm_session()); ![...] !static Pd_root pd_root(e, e, pager_ep, &pd_sliced_heap);
- The CR service is registered and the special Sliced_heap is passed to
the Root_component<Cr_session_component> object.
In base/src/core/main.cc: !static Cr_root cr_root(e, &sliced_heap, &pd_sliced_heap); ![...] !static Local_service ls[] = { ! Local_service(Cr_session::service_name(), &cr_root), ![...] !}
- In the implementation of the checkpoint method the Sliced_heap
(stored in _alloced_pds) is searched for a Pd_session_component with a specific label string. The class implementing the Cr service (Genode::Cr_session_component : Rpc_object<Cr_session>) is a friend class in Sliced_heap and is allowed to access the _blocks member variable containing the Pd_session_component objects.
In base/src/core/include/cr_session_component.h (newly created file): !bool checkpoint(String<64> label) !{ ! Pd_session_component *pd = nullptr; ! bool found = false; ! Sliced_heap::Block *b = _alloced_pds->_blocks.first(); ! for(; (b != 0) && !found; b = b->next()) ! { ! pd = reinterpret_cast<Pd_session_component*>(b + 1); ! if(label == pd->_label.string) found = true; ! }
- The Pd_session_component object is known and now it shall be used to
access the test component's address space content. To retrieve the content I want to attach the Dataspace of the component's Region_map to core's Region_map.
In base/src/core/include/cr_session_component.h (newly created file): ! Capability<Region_map> rm_cap = pd->address_space(); ! Region_map_client rm_client(rm_cap); ! void* addr = core_env()->rm_session()->attach(rm_client.dataspace()); ! return true; !}
- After invoking rm_client.dataspace() the Rpc method never returns and
the test scenario times out.
What am I doing wrong? I compared the source code of other core services with the CR service and found no usage of classes derived from Rpc_client belonging to other core services. Is it not possible to use Rpc methods in core?
I tested another solution where I only use Rpc_objects directly. I used pd_session_component::address_space_region_map() to access the address_space directly, where I think to find the memory content of the test component (Please correct me, if I am wrong). The following listing replaces the listing in step 4.
In base/src/core/include/cr_session_component.h (newly created file): ! Dataspace_capability ds_cap = pd->address_space_region_map().dataspace(); ! char* addr = core_env()->rm_session()->attach(ds_cap); ! log("Attaching dataspace: Returned pointer: ", addr); ! ! Dataspace_component *ds_comp = pd->address_space_region_map().dataspace_component(); ! log("Reading dataspace component"); ! log("phys_addr = ", ds_comp->phys_addr(), " size = ", ds_comp->size(), " writable = ", ds_comp->writable() ? "true" : "false");
The output of the log function was the following: Attaching dataspace: Returned pointer: 0x00000000 Reading dataspace component phys_addr = 0 size = 3221221376 writable = false
Now I got a null pointer and cannot read the content of the Region_map of the test component.
Can someone help me to answer the following questions:
- Can I use Capability invokation in core, where the Rpc_object belongs
to another core service? If yes, how? Perhaps, my problem is the correct retrieval of the Pd_session_component, thus I can invalid Capabilities.
- Why do I get an invalid pointer from the attach method of core's
Region_map? Is it not allowed to attach dataspaces in core? Are they already attached in core, and I only need the pointer to the memory? Is the Dataspace_capability invalid?
Kind regards Denis
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main