Improve dependencies newlib -> libcglue -> fio/fileXio

[fjtrujy]

Hello,
I was working on improving the usage of fio vs fileXio, however, I'm facing some problems during linking, and I think that most of them are related to circular dependencies.

Let's put an example, (forgetting for now fileXio) open a file.

fd = open("foo.txt", O_RDONLY | O_CREAT); 

The path that will follow to execute this line is:

1. Implementation of open is on newlib, and it will call the function _open
2. Implementation of _open is on libcglue and it will call the function fioOpen
3. Implementation of fiOpen is on kernel

So so far we have newlib -> libcglue -> kernel, which is totally fine. But we need to assure that we aren't using any newlib functionality from kernel folder, such as malloc or some string operations.
If we do, then we have circular dependencies.
newlib -> libcglue -> kernel -> newlib

I don't know currently the places where this was happening, but that's the reason why we have this https://github.com/ps2dev/gcc/blob/ee-v11.3.0/gcc/config/mips/ps2sdk.h#L2-L9

#define LIB_SPEC "\
    -lm \
    --start-group \
        %{g:-lg} %{!g:-lc} \
        -lcdvd \
        -lcglue \
        -lkernel \
    --end-group"

As you can see, we're creating a group (--start-group) for solving these circular dependencies.

At the very beginning, I mentioned that I wanted to improve the usage of fio vs fileXio, so let me explain why.

Currently, most of us are using the fileXio for our applications, and the way that we are using fileXio instead of fio is by calling fileXioInit, this will override the pointer functions for all the "glue functions" required by newlib.
How this is happening in runtime, our binary will contain all the fio functions + fileXio functions having a bigger binary and also
could create some issues.

I wanted to remove this duplication (fio + fileXio) by following the same strategy that I used before in other PRs.
Defining weak implementation for fio (being the default ones), and strong implementations for fileXio, finally in the case that the user wanted to use fileXio just linking the -lfileXio should be enough.

As a test, I did a dummy example:

int main()  
{
   int fd;
   fd = open("foo.txt", O_RDONLY | O_CREAT);   
   printf("fd = %d/n", fd);
   
   return 0;
}

And using mips64r5900el-ps2-elf-objdump -D {binary} I wanted to check the symbols used.
Even linking with -lfileXio I still saw fio functions.

The main reason (I think) it is the --start-group defined in the https://github.com/ps2dev/gcc/blob/ee-v11.3.0/gcc/config/mips/ps2sdk.h#L2-L9

If instead of linking -lfileXio normally we do as -Wl,--whole-archive -lfileXio -Wl,--no-whole-archive then, the binary will use the fileXio functions.

So this is why I would like to discuss how to be sure that we aren't having circular dependencies.

As a starting point, I think that we should separate fio from lkernel library, calling to functions such as ps2sdk_open from kernel, and then to have 2 separate implementations:

• libfio -> weak implementation and default one
• libfileXio -> strong implementation and it is up to the developer to link it.

I still don't have the whole picture in my head, but I would like to listen your thought, specially from @uyjulian @rickgaiser @AKuHAK and specially @sp193

Cheers