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_tutorial 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 -- 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 ------------------------------------------------------------------------------ Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis & security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk _______________________________________________ Genode-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/genode-main
