Hello Meenakshi,
On 02/25/2014 11:39 AM, Meenakshi Narayanan wrote:
As far as the session interfaces are concerned, the framework is very intricately designed (hats off). Connection->Client->Capability->Session. If I want to call a function defined by the session interface, one has to include the <session_name>/connection.h and make a call which then calls the Rpc_functionName. My question is this: Where is the body of such functions defined? Is there a framework that dictates where the body of the function goes?
the short answer is that RPC interfaces are implemented in classes named '*_component'. E.g., the implementation of the 'Io_mem_session' interface can be found in the form of the 'Io_mem_session_component' class in base/src/core/include/io_mem_session_component.h and the corresponding io_mem_session_component.cc file.
To get a profound understanding of how RPC-based inter-process communication works on Genode, I recommend to walk through the following tutorial:
http://www.genode.org/documentation/developer-resources/client_server_tutori...
It will hopefully clear up a few misunderstandings about the terminology.
Recently, my friend Aditya posted this http://sourceforge.net/mailarchive/forum.php?thread_name=CANhviG0%3DKY2%3D%3DRQxUVDsF-BhitHHS1S0uD70NXzTyb%3DBakXUyw%40mail.gmail.com&forum_name=genode-main and it gave the error 'No RM attachment', which is found in the function print_page_fault defined in util.h. My assertion is that a component that uses the MMIO class initlaiised with this dataspace().local_addr() rather than the physical address itself.
Long story short, what could have caused this page fault?
The "No RM attachment" message basically corresponds to "segmentation fault" on Linux. Your program apparently accesses an invalid memory location. There can be many reasons, e.g., a dangling pointer. Without being able to reproduce it, I am unfortunately not able to provide much aid for debugging your problem.
Depending on the kernel you are using, the error message may provide you with some additional information: The instruction pointer where the fault occurred and the page-fault address. The first step I would take is to look up the instruction pointer in your binary (using 'objdump -lSd | less', then searching for the address) to inspect the offending instruction and the surrounding code. Additionally, the fault address might give you a hint about the nature of the fault. If it is a very small value, your program has likely dereferenced a null pointer. If the value starts with '0x4...', the fault occurred somewhere within the so-called thread-context area where the stacks are located. So your program will most likely have produced a stack overflow.
Best regards Norman