Question regarding linking, cross-compiling

[Luns]

Following the OS-Specific Toolchain wiki article, I have build what seems to be a working cross compiler for my operating system. The problem is that I think it's being linked with the entire newlib library, as the resulting binaries are huge - an empty program which just does nothing but return ends up being 37K large. readelf shows all sorts of stuff in the file - getpid, lseek, wait, etc.

I assume what I should be doing is loading newlib's libc as a shared library, and then dynamically link my programs against that. Is that correct?

Thanks in advance!

[OSwhatever]

Shared library seems to be the way to go if you want to reduce the memory usage while using GCC with newlib. 37K is small compared to when you include C++ std library, then the binaries become ~250K. Shared library support will do wonders for your memory consumption in this case, especially for micro kernels that has loads of small programs.

[Luns]

Alright, shared it is.

Are the standard lib*.a files created when building newlib suitable to be used as a shared library, or do I need to rebuild them with different flags to make them into shared libraries? Searching around here it looks like all I have to do to make it into a shared library is 'ar -x libc.a; ld -shared *.o -o libc.so', is that correct?

[gerryg400]

I don't think shared v static is your problem. The linker should only include files that contain code or data that is used. If you are not calling getpid, lseek, wait, etc. then are you calling a function or using data that shares a files with them ?

For example, perhaps your startup code looks like this

Code: Select all

FILE crt0.S

    ...
    call main
    call _Exit

and perhaps the _Exit function shares it's source file with some other functions.

If you really have a program that does 'nothing', then there should be no code at all linked in from the library.

[Luns]

The program I'm compiling truly does nothing except return 0. It should be linked with crtbegin.o and crtend.o though, but I don't think those would bring in all that much more, right?

I assume then I did something wrong in building my cross-compiler? The reason I assumed it was linking in the library was because if I passed -nostdlib, the binary was a more normal size.

And thanks for taking a look at this, both of you.

[gerryg400]

As an experiment I modified my crt0.S so that it looked like this

Code: Select all

.text

.globl _start
.extern main

 _start:
    call main
    // call exit
.wait:
    hlt
    jmp .wait

My program that just does return 0 is less than 4k. When I disassemble it I can see 3 segments (.init, .text and .fini). The .init and .fini segments are just a few bytes each. The .text segment contains the following symbols.

Code: Select all

_start
.wait
__do_global_dtors_aux
frame_dummy
main
__do_global_ctors_aux

Normally, however, my crt0.S calls exit. This drags in a lot of newlib (atexit functions, fcloseall, pthread_exit stuff). My "return 0" exe is about 48k so I think you have nothing to worry about.

[OSwhatever]

For bare bones I suggest you compile it with.

gcc: -ffunction-sections
ld: --nmagic -static

This causes at least the elf-file itself to become smaller and has no large internal section alignment. You can use libc with barebones for a few selected functions as well.

[Luns]

Thanks very much for taking the time to test that out, gerryg. It gives me confidence I haven't totally messed up so far...

And thanks for those options OSwhatever, I'll look into those.

Now my question is this - presumably, I will eventually write a dynamic linker and load libc as a shared library since statically linking each program seems excessive. So should write that now, or should I write the statically linked program loader first? It seems like it might end up taking a fair amount of work getting the statically linked program loader working, and I wouldn't want to put all that effort into writing something that will soon never be used. But then, perhaps there's some other reason I would need to load statically linked programs?

[OSwhatever]

Now my question is this - presumably, I will eventually write a dynamic linker and load libc as a shared library since statically linking each program seems excessive. So should write that now, or should I write the statically linked program loader first? It seems like it might end up taking a fair amount of work getting the statically linked program loader working, and I wouldn't want to put all that effort into writing something that will soon never be used. But then, perhaps there's some other reason I would need to load statically linked programs?

I suggest you start with loading statically linked elf-files. There are many things that should have higher priority in the OS development list. I don't think you will run out of memory since you probably have very few programs/modules to begin with unless you have a very little RAM memory.

[Luns]

That's a good point, thanks.

I've almost worked out a functional statically linked program loader, and have written a message to the screen from a program loaded from disk. It feels good