Method definitions for session interfaces

[Norman Feske]

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