OSDev.org

Good day!

I'm porting standard C library for bare metal "OS" (ARM Cortex-M4, ARM GCC [1]). I want to have functions like strlen, sprintf, (and memory allocator, maybe), etc.

I've ported PDCLib [2] and Newlib [3].
But both are not lightweight (and try to implement files operations, etc.).
PDCLib 1) need lgcc, 2) have some ARM issues (so, ARM is not maintained), 3) is not in active development.

So, I want Microlib [4] exactly. But it's not for GCC and closed source.

Are there some alternatives for this? And are there some "bare metal subsets" of standard C Library? Thanks.


---

[1]: https://developer.arm.com/open-source/g ... ain/gnu-rm
[2]: http://pdclib.e43.eu/
[3]: https://sourceware.org/newlib/
[4]: http://www.keil.com/support/man/docs/ar ... 938431.htm

Take any standard library and copy just those parts that you're interested in. Things like the string functions shouldn't depend on anything else in the libraries.

kuraga wrote:PDCLib 1) need lgcc,

All code compiled with GCC requires libgcc.

kuraga wrote:PDCLib 1) need lgcc, 2) have some ARM issues (so, ARM is not maintained), 3) is not in active development.

1) PDCLib does not need anything. (See reply by Octocontrabass.) It's as lightweight as you can get without dropping parts of the standard. My original concept was, you need a "complete" C standard library in any case sooner or later, so why bother with a "kernel / bare metal subset". You can easily cut away parts of PDCLib manually if they don't suit you (e.g., just don't include <stdio.h> and its implementation if you don't need it).

2) What are those ARM issues you are speaking of? I would be interested to hear them.

3) You are correct. At some point (shortly after releasing <stdio.h>) I couldn't bear working on this project anymore, and passed the lead to Owen. PDCLib then reached the point where it did what Owen wanted it to do, so his activity waned. I picked up work on PDCLib again for some time, and found that I would have to do some "clean-up work" first as I could not really make left and right of some of Owen's work. I did some of that in the "retrace" branch. Eventually, it turned out that I prioritized other interests in life over PDCLib; but I still have access to the repo and might do something about 2).

Solar,
thanks for reply!

1) PDCLib does not need anything. (See reply by Octocontrabass.) It's as lightweight as you can get without dropping parts of the standard. My original concept was, you need a "complete" C standard library in any case sooner or later, so why bother with a "kernel / bare metal subset". You can easily cut away parts of PDCLib manually if they don't suit you (e.g., just don't include <stdio.h> and its implementation if you don't need it).

It can't be compiled with -nostdinc option (even if "platform" is empty). For example we need "sys/mmap.h" in dlmalloc. Amn't I right?

2) What are those ARM issues you are speaking of? I would be interested to hear them.

Well, sorry, I'm not sure that should be PDCLib questions... I talked about division in sprintf which isn't implemented.

P.S. I didn't talk that PDCLib is bad. Well, I wasn't right: PDCLib is really lightweight (now I have six hours more experience with it and Newlib ). Also I noted some other interesting moments about porting in code (I don't say bugs) - I'll write about them on issue tracker and/or here.

Thanks very much!

kuraga wrote:It can't be compiled with -nostdinc option (even if "platform" is empty). For example we need "sys/mmap.h" in dlmalloc. Amn't I right?

You shouldn't use -nostdinc. You might be thinking of -nostdlib instead, which you do need to compile your C library.

Headers like sys/mman.h are OS-specific. You'll either write your own POSIX-compatible sys/mman.h or write the support code so dlmalloc can use your OS's equivalent of mmap().

Then I was wrong. Apologize.

But we need porting guide

Search and you will find: http://wiki.osdev.org/Porting_Newlib
This applies to other C libraries as well.
Though exact filenames and contents could be different it should be easy enough to adapt.

FusT,

in my previous message I talked about PDCLib porting guide. It's absent.

If you don't know what you're doing while porting, it might be best not to port things for now but write your own code instead in order to get the experience needed for porting existing software.

The PDCLib source specifically contains a readme file that tells you what to do. It's short, but it should be enough if you have the required experience because porting PDCLib is really easy:

For adapting PDCLib to a new platform (the trinity of CPU, operating system, and compiler), make a copy of ./platform/example/ named ./platform/{your_platform}/, and modify the files of your copy to suit the constraints of your platform. When you are done, copy the contents of your platform directory over the source directory structure of PDCLib (or link them into the appropriate places). That should be all that is actually required to make PDCLib work for your platform.

Kevin,

written but it's not true. For example, I need also port "sys/mmap.h" (as I said above) but isn't mentioned.

I've done this procedure, Kevin. And I did some additional things to get compiled PDCLib. And I don't know if 1) I've done it right, 2) are there things I haven't done.
(Note: I can't run tests cause I didn't realize most of syscalls).

I just said: It's good to have a porting guide for this good library. And added a smile btw. Isn't it correct??

I really don't understand why other questions replaced topic question: Are there open sourced libraries like Microlib?

kuraga wrote:For example, I need also port "sys/mmap.h" (as I said above) but isn't mentioned.

You think you need to port it, but you don't. I read the code.

What you need to do is "modify the files of your copy to suit the constraints of your platform", as the readme says. Specifically functions/_PDCLIB/allocpages.c for this one.

I just said: It's good to have a porting guide for this good library.

I think the point is that at a certain point you need to start working out things (at least simple things) by yourself. Getting PDCLib ported is not a very complicated thing to do, you just have to provide a few functions and you can even make part of them stubs that return errors unconditionally if you don't need the whole functionality. If you rely on detailed step-by-step tutorials for everything so you can just copy and paste, you'll never make real progress.

I really don't understand why other questions replaced topic question

Because asking for something less capable doesn't make sense in the first place. If you don't need functionality in some open source library and you want to get rid of it, just remove it. It's easy.

kuraga wrote:I really don't understand why other questions replaced topic question: Are there open sourced libraries like Microlib?

The point is that PDCLib was designed for generic OSDev work, in a way that few other libraries are likely to be. It is probably your best chance at getting what you are looking for.

Lacking a PDCLib discussion forum, I'll take the opportunity to talk about it right here, as I consider any perceived shortcomings of PDCLib in that particular role to be design defects.

One thing to note about PDCLib. When I passed the project to Owen, he pushed PDCLib towards a point where it was working for him (gandr). This included, aside from several bugfixes:

• time.h
• uchar.h
• threads.h
• wchar.h
• wctype.h
• manpages
• pthreads integration
• dlmalloc integration
• Jam build instead of Makefile

This work was commendable, and I am thankful Owen did it, as it showed the base work I did was scaling to production work. But when I picked up interest in the project again, I found some of those additions to be not quite up to the standards I had set myself in my original work. I also found it somewhat hard to turn them into that direction without ripping things apart. (Some things that should have been strictly optional were not, really.)

So I did set up a branch in the repository, called "retrace". It branches at the point I had left the project, and attempts to "retrace" the improvements and fixes Owen applied, piecemeal, while keeping "my" structure intact. I looked at Owen's "default" branch for inspiration, but added things "my way".

You get that branch via "hg update -rretrace".

Give it a try. It is not as advanced as Owen's work, but I have backported the bugfixes to the existing code, and added a time.h implementation of my own; but there is no hint of dlmalloc(), threads, or wide character support yet (as other things in my life took over).

Instead of dlmalloc, there is a really primitive "placeholder" function, allocpages(), that you could plug into your kernel specifics to "just get it working".

From what I understood, you are looking for a "no frills" library, and PDCLib "retrace" is probably closer to that than PDCLib "default".

I might get back to working on that PDCLib branch at some point in the future. While I have completely dropped out of OSDev work (for quite some time now), I quite enjoy tinkering with this project from time to time when I am bored. I just am no longer bored as much as I was back when I started PDCLib, or when I picked it up again this year...

kuraga wrote:FusT,

in my previous message I talked about PDCLib porting guide. It's absent.

You didn't read my full reply, especially this part:

FuST wrote:This applies to other C libraries as well.

Porting a standard C library like PDClib/Newlib, even without a manual, is not that hard. Just add the platform specifics and rip out stuff you don't need.
That's one of the great things of open source software.

Solar,

Thanks very much for your explanation, especially about retrace branch (I saw notes about it at this forum but I didn't understand that these changes are so important).

As I said above I've already changed my IMHO about PDCLib and I apologize about my incorrect information in this thread about PDCLib. Yes, "without frills" and it is studying task, too. And there are no questions about maintanance, sure I understand situation. I've finished porting to bare metal ARM (without system calls) and my program with sprintf is working now

One more question about memory allocation. (Note: I'm a beginner here and I might say something wrong). We need to implement _sbrk function only in Newlib (and PDCLib's retrace branch, as I see) for memory allocation. In dlmalloc we need sys/mman.h, etc. Question: is it just design (which could be another) or is it involved with MMU/MMU-less?

P.S. For "minimal bare metal" porting, i.e. 1) compiling lib without header/libs and successful compiling and 2) running code with sprintf, I (on default branch):

• added a new platform directory/code. I chosen nothread option, added -nostdinc and -nostdlib flags,
• removed functions/_dlmalloc code, because we need system headers and libraries instead,
• ARM specific: #define _PDCLIB_CHAR_SIGNED 0 (but it can't be removed though comment before recommends that),
• ARM specific: fix division issues.

Note that is an instruction for minimal program (not running (subset of) test suite).

Also we don't have *exit* library functions and there are warnings about noreturn. I don't know how to handle this correctly.

Also I think platform/minimal/functions/stdio/remove.c (and function inside) is _PDCLIB_remove instead of remove. By the way it's already declared in platform/minimal/internals/_PDCLIB_config.h but isn't implemented.

Thanks.

P.S. So, default should be merged into retrace or retrace into default?