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:
>>
>> 1) 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);
>> ! }
>> !}
>>
>> 2) 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);
>>
>> 2) 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),
>> ![...]
>> !}
>>
>> 3) 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;
>> ! }
>>
>> 4) 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;
>> !}
>>
>> 5) 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
>
--
Stefan Kalkowski
Genode Labs
https://github.com/skalk ยท http://genode.org/
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
