Hi guys, here are the updates 2 & 3 of the 3rd Milestone in #SAoC2020.

My last post is at [1]. My plan was:
- to continue building the DRuntime with the necessary modules;
- to solve the errors that could appear.

What I did was:
- continued adding the modules until there were no errors related to modules that were not imported;
- I got an error with an undefined reference to 'stderr'; this symbol is provided (on any other target) by the C standard library (the 'stderr', 'stdout' and 'stdin' symbols are defines using the 'extern' attribute in core/stdc/stdio.h);
- to solve the error, I started versioning the core/stdc/stdio.h and defined those symbols in the same way they are defined in newlib (I will probably import the newlib library later).
- I successfully compiled a TockOS application written in D and linked it with the DRuntime with no other errors; the final size of the DRuntime was around 1.7 MB which is a big improvement from the last final size (~2.5MB).
- I had problems with the emulator and lost some time configuring and installing different versions of the Renode emulator.

This week I am planning to do the following:
- solve the emulator problem, again, and hope to have a working testing environment;
- probably I will start versioning the DRuntime with this new architecture, if the application will run correctly on the emulator;
- if any errors appear, I will dig in my current setup to solve them.

[1]: https://forum.dlang.org/post/ldvbetlrenxwwhkygnbh@forum.dlang.org

On Friday, 11 December 2020 at 10:16:41 UTC, Severin Teona wrote:
> - to solve the error, I started versioning the core/stdc/stdio.h and defined those symbols in the same way they are defined in newlib (I will probably import the newlib library later).

private extern(C) _reent *__getreent();

FILE* __stdin()() { return cast(FILE*)(__getreent()._stdin); }
FILE* __stdout()() { return cast(FILE*)(__getreent()._stdout); }
FILE* __stderr()() { return cast(FILE*)(__getreent()._stderr); }
///
alias __stdin stdin;
///
alias __stdout stdout;
///
alias __stderr stderr;

Is this how you solved stdin/out/err?

On Friday, 11 December 2020 at 10:27:29 UTC, IGotD- wrote:

> private extern(C) _reent *__getreent();
>
> FILE* __stdin()() { return cast(FILE*)(__getreent()._stdin); }
> FILE* __stdout()() { return cast(FILE*)(__getreent()._stdout); }
> FILE* __stderr()() { return cast(FILE*)(__getreent()._stderr); }
> ///
> alias __stdin stdin;
> ///
> alias __stdout stdout;
> ///
> alias __stderr stderr;
>
> Is this how you solved stdin/out/err?

Not exactly. I used a struct __sFile_fake for each one of stdin/out/err, like in newlib/libc/include/sys/reent.h.

I did this after I compiled a simple C application with the -E flag (only preprocessing) and I saw that stdin/out/err were translated to _impure_ptr->_stdin/out/err. I searched for these symbols in newlib and I found them in reent.h.

I don't know how accurate and right is it, but it seems to link the application ok.

On Friday, 11 December 2020 at 12:51:53 UTC, Severin Teona wrote:
> On Friday, 11 December 2020 at 10:27:29 UTC, IGotD- wrote:
>
>> private extern(C) _reent *__getreent();
>>
>> FILE* __stdin()() { return cast(FILE*)(__getreent()._stdin); }
>> FILE* __stdout()() { return cast(FILE*)(__getreent()._stdout); }
>> FILE* __stderr()() { return cast(FILE*)(__getreent()._stderr); }
>> ///
>> alias __stdin stdin;
>> ///
>> alias __stdout stdout;
>> ///
>> alias __stderr stderr;
>>
>> Is this how you solved stdin/out/err?
>
> Not exactly. I used a struct __sFile_fake for each one of stdin/out/err, like in newlib/libc/include/sys/reent.h.
>
> I did this after I compiled a simple C application with the -E flag (only preprocessing) and I saw that stdin/out/err were translated to _impure_ptr->_stdin/out/err. I searched for these symbols in newlib and I found them in reent.h.
>
> I don't know how accurate and right is it, but it seems to link the application ok.

That would work too I guess. The thing is that the reent structure is initialized every time for every thread with stdin/out/err with globals so it should be the same for each thread too if you have dynamic reent enabled. When you compile without dynamic reent structure __getreent() will simply pass _impure_ptr which in turn points to a global reent.

On Friday, 11 December 2020 at 12:51:53 UTC, Severin Teona wrote:
>
> Not exactly. I used a struct __sFile_fake for each one of stdin/out/err, like in newlib/libc/include/sys/reent.h.
>
> I did this after I compiled a simple C application with the -E flag (only preprocessing) and I saw that stdin/out/err were translated to _impure_ptr->_stdin/out/err. I searched for these symbols in newlib and I found them in reent.h.
>
> I don't know how accurate and right is it, but it seems to link the application ok.

However, __getreent is more future proof because we don't know if the Newlib code will change the name of the globals in the future as that is internal code. __getreent is a feature of Newlib that will not go away.

On Friday, 11 December 2020 at 10:16:41 UTC, Severin Teona wrote:
> the final size of the DRuntime was around 1.7 MB which is a big improvement from the last final size (~2.5MB).

Can you show $ size your_binary_file command output?

On Friday, 11 December 2020 at 14:33:17 UTC, IGotD- wrote:
> However, __getreent is more future proof because we don't know if the Newlib code will change the name of the globals in the future as that is internal code. __getreent is a feature of Newlib that will not go away.

Okay, thanks a lot for the advice. I'll give it a try this week and see if I can make it work.

On Friday, 11 December 2020 at 21:22:51 UTC, Denis Feklushkin wrote:

> Can you show $ size your_binary_file command output?

Hi Denis, you are referring to the final DRuntime library, or to the final application that I am flashing on the board?

On Monday, 14 December 2020 at 07:17:45 UTC, Severin Teona wrote:
> On Friday, 11 December 2020 at 21:22:51 UTC, Denis Feklushkin wrote:
>
>> Can you show $ size your_binary_file command output?
>
> Hi Denis, you are referring to the final DRuntime library, or to the final application that I am flashing on the board?

Better if final application with all enabled size optimizations.

Currently I reached binary with about 200Kb ROM consumption. It contains druntime and simple blinky loop.