Board.KolibriOS.org

Summary of the project: Building a C layer for KolibriOS, so that we can get more developers and port more code to KolibriOS more easily.
Wiki: http://wiki.kolibrios.org/wiki/Google_S ... _KolibriOS
Student: punk_joker (Sergei Sakhno)
Mentor: Albom (Oleksandr Bogomaz)

Timeline (from the proposal):
​22 april ­ 30 May : Writing wrappers for main libraries and example program: box_lib (support for other components), proc_lib, libini, libio, http, rasterworks, kmenu.
30 May ­ 13 June: Writing wrappers for libimg, libgfx, archive, buf2d, xml, libcrash
13 June­ 27 June: Writing wrappers for other libraries, the organization structure of the project and writing mefiles example, for easy assembly of custom applications
20 June 19:00 UTC Mentors and students can begin submitting mid­term evaluations.
27 June Mid­term evaluations deadline; Google begins issuing mid­term student payments provided passing student survey is on file
27 june ­ 15 Aug: Working with a mentor on another task: the beginning of work on the porting of PolarSSL, or rewrite uPDF on newlib, and to further improve program.

Hi, punk_joker!
Let start working on the project!

Я тут немного огляделся. Пару предположений для задачи:

1.Сейчас не все системные функции имеют вызовы в тулчейне gcc.

2.Обертки для вызовов нужны для всех библиотек в /sys/lib, и возможно некоторых многообещающих типа xml. Список к обсуждению долгожителям.

3.Желательно поддерживать не только кросс компиляцию, но и родную с помощью tinyc (ktcc).

4.Я бы предложил стандартизовать fastcall соглашение для оберток. Единственное но на данный момент - tinyc придется поднять до версии 0.9.24

Siemargl wrote:Я тут немного огляделся. Пару предположений для задачи:

1.Сейчас не все системные функции имеют вызовы в тулчейне gcc.

Будет.

Siemargl wrote:2.Обертки для вызовов нужны для всех библиотек в /sys/lib, и возможно некоторых многообещающих типа xml. Список к обсуждению долгожителям.

По моему proposal видно, что я собираюсь сделать обертки для большого числа библиотек, имеющихся для KolibriOS, не только тех, что имеются в составе дистрибутива.

Siemargl wrote: 3.Желательно поддерживать не только кросс компиляцию, но и родную с помощью tinyc (ktcc).

4.Я бы предложил стандартизовать fastcall соглашение для оберток. Единственное но на данный момент - tinyc придется поднять до версии 0.9.24

По окончанию работы над первыми 2 пунктами, займусь этими.

Siemargl wrote:4.Я бы предложил стандартизовать fastcall соглашение для оберток.

I think it would be better to make inline functions.

My experience in Porting Netsurf says that we should have a function free_asm() which is callable from C and let's you free memory block allocated with MCALL 68,12 . Basically, free_asm() should be wrapper on top of MCALL 68,13 . This is because if use libc's free() on memory block allocated from MCALL 68,12 from the heap, free() crashes . It is NOT a bug in free because free() expects that the block was allocated using malloc() .

Btw, shouldn't our malloc() implementation be based on mcall 68,12 and free() based on 68,13 so that everything remains the same in C as it is in assembly?

System function allocates 4K blocks. My malloc realization uses sysfunc directly... It is very irrationally. So there is a need in memory manager. But I think newlib and menuetlibc already use it.

Albom wrote:

Siemargl wrote:4.Я бы предложил стандартизовать fastcall соглашение для оберток.

I think it would be better to make inline functions.

1. I doubt that compiler can inline functions which calling other functions (non trivial)

2.kttc fails (crashes) with inlining today.

ashmew2, in newlib just call user_free(). It's sysfn 68.13.

Siemargl wrote: 2.kttc fails (crashes) with inlining today.

maybe need ports new version?

punk_joker wrote:

Siemargl wrote: 2.kttc fails (crashes) with inlining today.

maybe need ports new version?

I have some misunderstanding at this point:
-in manual with 0.9.23 states: inline keyword is ignored.
-but a have a stacktrace

Spoiler:

(gdb) bt
#0 0x772ee024 in ntdll!RtlFreeHeap () from E:\windows\system32\ntdll.dll
#1 0x75ae98cd in msvcrt!free () from E:\windows\syswow64\msvcrt.dll
#2 0x00610000 in ?? ()
#3 0x00402eec in tcc_free (ptr=0x2f0) at tcc.c:1037
#4 0x00404f2c in tok_str_free (str=0x2f0) at tcc.c:2322
#5 0x00411bff in gen_inline_functions () at tcc.c:8962
#6 0x00412400 in tcc_compile (s1=0x612bd8) at tcc.c:9249
#7 0x0041d72f in tcc_add_file_internal (s1=0x612bd8,
filename=0x6129b1 "clipview.c", flags=1) at tcc.c:9911
#8 0x0041d96d in tcc_add_file (s=0x612bd8, filename=0x6129b1 "clipview.c")
at tcc.c:9997
#9 0x0041e835 in main (argc=5, argv=0x612ba8) at tcc.c:10700
(gdb)

and after removing all inline keyword problem is gone.
It's not inlining problem. Just memory deallocation fail. Workaroud - comment free() in tcc_free()

Need to go deeper.
Maybe new version fixed this maybe not.

I've seen some versions @github and @home tinyc site. Later do comparing.

Upd.
There is a problem in linker, which can link executable without a needed function and no error. Upd. Fixed this in 0.26
And libc from ktcc is awful - completely unusable - every step find bugs (some i fixed, but its a long way)
Fixed minimum to work, laid on SVN

The primary goal is to write a wrapper libraries, and toolchain from Serge, then the completion newlib if necessary (support for all system calls) .It plans in the first half, in the second half, it will be possible to do ktcc, and compiling them all of this, right under KoibrioS.

I've just ported tinycc 0.9.26-27 (current from github)

Some errors gone, but still need work for native kos compiler executable (just runs, no result).

Sorry, it works (but silently). I prepare to run internal tests, check some incompatibilities in source code parsing and check its mini libc.

Finished.

I add wrapper for a console.obj in ktcc project
http://websvn.kolibrios.org/filedetails ... %2Fconio.c

also see include/conio.h

Siemargl wrote:I add wrapper for a console.obj in ktcc project
http://websvn.kolibrios.org/filedetails ... %2Fconio.c

also see include/conio.h

Nice!
The name conio.h reminds me of the first C Compiler I used, BORLAND TURBO C.

A detailed plan for the first half:

25 may - new project structure, example programm and makefile
27 may - final work on box_lib
29 may - wrapper for kmenu
2 june - wrapper for libimg (you need to deal with some issues)
5 june - libini, libio
9 june - archive
11 june - rasterworks
13 june - libgfx
15 june - buf2d
17 june - xml
18 june - libcrash
18 - 20 june - inspection checking, correcting possible errors

punk_joker wrote:A detailed plan for the first half

OK. I would like to see results as soon as possible.