Hello everyone, I'm porting Bionic Libc on to Genode. Even though there are few warnings that needs to be resolved, the library is compiling fine so far. I have a problem in running the library.
In normal libc, in its test application main.cc(/repos/libports/src/test/libc, consisting of only printf statments), if I comment the inclusion of *stdio.h* instead *using namespace Genode* then it prints the statements as it is supposed to print with libc. As far as my understanding it is using the Genode printf() help to print the statements, not the libc printf().
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.
Hello Paramesh,
On 04/22/2015 12:20 PM, Paramesh Oddepally wrote:
But, in my library(bionic), the same thing is not working afterthe 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 [1]. 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.
[1] https://github.com/genodelabs/genode/tree/master/repos/libports/src/lib/libc
Good luck! Norman
Hello Norman, 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@...1...> wrote:
Hello Paramesh,
On 04/22/2015 12:20 PM, Paramesh Oddepally wrote:
But, in my library(bionic), the same thing is not working afterthe 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 [1]. 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.
[1]
https://github.com/genodelabs/genode/tree/master/repos/libports/src/lib/libc
Good luck! 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
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 exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hello Paramesh,
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?
since your program states "using namespace Genode", the compiler resolves the "printf" symbol by using 'Genode::printf', which is provided directly by the Genode environment and is independent from the libc. If you want to make sure to *not* call 'Genode::printf', omit the "using namespace Genode" directive. Alternatively, you may change "printf" to "::printf" to explicitly tell the compiler your intention.
As per the debug messages that I have, bionic is exactlystopping just after the parsing of config (taking the file path given to stdout). Am I missing out something here?
To investigate the point where the program gets stuck, I would run the scenario on base-linux, list all Genode threads via 'ps -eLf | grep Genode' and attach to GDB to the thread in question using 'gdb -p <thread-id>'. In GDB, you can conveniently obtain a backtrace with the 'bt' command.
Cheers Norman
-
Norman Feske -
Paramesh Oddepally