library porting problem
paramesh014 at ...9...
Thu Apr 23 07:01:16 CEST 2015
Thank you for your detailed explanation. Yes. I understood
the importance of the back end between library and Genode and hence
provided the implementation that looks similar to the libc back end but I
forgot to mention it in earlier mail. So far, it looks fine for me.
For the situation just mentioned above(stdio.h exclusion and
Genode namespace inclusion in repos/libports/src/test/libc/main.cc, I have
attached the file as reference) it looks like the printf's in main.cc are
completely bypassing the library(not touching the functions of libc). Is it
not?? If it is, then it is using the printf() in Genode directly with out
using the plugins of libc and hence the printf's in bionic's testing
main.cc(same as attached) should also need to print right?
As per the debug messages that I have, bionic is exactly
stopping just after the parsing of config (taking the file path given to
stdout). Am I missing out something here?
On Wed, Apr 22, 2015 at 7:20 PM, Norman Feske <norman.feske at ...1...>
> Hello Paramesh,
> On 04/22/2015 12:20 PM, Paramesh Oddepally wrote:
> > But, in my library(bionic), the same thing is not working after
> > the same changes as above(with same main.cc ). Its not printing anything
> > and waiting infinitely. I cannot understand how to interpret this
> > problem, Is it problem with Library?
> > The run file of my library is similar to the /libc/ run file.
> merely compiling the library for Genode is merely the first (and
> probably the easiest) step of porting a C runtime like Bionic to Genode.
> The main part of the work is the creation of a libc "back end" that acts
> as the glue between the C runtime and the underlying Genode system. To
> give you an idea of the role of this glue, here are two examples:
> * The back end has to provide the memory for the C runtime's malloc and
> free functions. On Linux, the back end of the C runtime performs a
> mmap system call to obtain chunks of anonymous memory to be used at
> malloc/free backing store. On Genode, your back end would have to use
> Genode's RAM session and RM session interfaces instead.
> * For input and output (I/O), the back end has to translate I/O function
> calls (like read, write, stat, etc) to Genode's various session
> interfaces (terminal session, file-system session, log session, etc).
> This is far from trivial because, unlike a POSIX system, Genode does
> not have mechanisms that perfectly correspond to the C runtime
> function calls. For example, on Genode, there are no file descriptors.
> So the back end of the C runtime needs to emulate the semantics of
> file descriptors by using Genode's mechanisms.
> To implement a back end for the Bionic C runtime, you may take cues from
> the back end of our existing libc, which you can find at . But in
> order to go ahead, you will ultimately need to gain a good understanding
> of the internal structure of the Bionic library.
> I would start with stdout (as you just tried). You first need to
> determnine the back-end function called by the Bionic library when
> issuing the printf function, e.g., by following the call graph within
> the Bionic library. On a Linux system, the back end of the Bionic libc
> will eventually issue a "write" system call. Your custom back end would
> instead issue a call to Genode::Log_session::write.
> Good luck!
> 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
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> genode-main mailing list
> genode-main at lists.sourceforge.net
Thanks and Regards,
Department of Computer Science and Engineering
I.I.T. Madras, Chennai, India
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 653 bytes
Desc: not available
More information about the users