gcc option for pure executable file

[zq]

I do not mean a binary file, I know it as well as servel option like -nostdlib and -ffreestanding, what I what to express is that gcc always generate the file with advanced feature like .eh_frame section and glt(maybe in the future there will be more)，I can disable it by proper option, but problem is that, can I disable all of it totally and generate a pure executable file which include only enssential .text .data .rodata and .bss section

[matt11235]

You could use objcopy to pull out what you wanted after the build.

[zq]

You could use objcopy to pull out what you wanted after the build.

you're right but there is risk for example what if the program depend on another section?

[nielsd]

Why do you want to discard the other sections in the first place? What problem are you trying to solve or what are you trying to accomplish?

[iansjack]

Just create a custom linker script file that only includes the sections you want.

[alexfru]

Why do you want to discard the other sections in the first place? What problem are you trying to solve or what are you trying to accomplish?

In my understanding the problem is that there's a lot of stuff modern compilers put into executables and one needs to either understand all of it and properly handle it or find a sure way to simplify things to a manageable level. This is exacerbated by the fact that things keep changing (optimizations, options, sections change) and old recipes and shortcuts may stop working any time you pick up a newer version of the compiler (everybody seems to like new toys!).

A dumber and a more stable compiler might actually be an easier option for someone making their first steps in OS development and learning the target architecture. I have a C compiler like that (Smaller C). It is very permissive (because it's not optimizing and not blowing your little bugs out of proportion), it produces simple executables (flat, a.out, PE, ELF, DOS .EXEs), but it has certain limitations and may not be great for everyone or everything (there are limitations in: the language, diagnostic messages, debugging support, did I mention lack of optimization?). But you can do something with it that you can't do with other modern compilers. You can compile C code for 16-bit real or virtual 8086 mode with it (multi-segmented with code/data larger than 64KB (Open Watcom might be the only alternative here but it's got its own problems)). And it supports unreal mode too, great for legacy (that is, non-UEFI) boot loaders.

[OSwhatever]

1. Create a linker script that ensures that your code+data is put into one load section. Pay attention to the BSS data as it will probably not we inserted into the file. You might want to solve this programmatically inside you code to initialize BSS.
2. Use objdump to dump out that section and you have a raw binary file.

[iansjack]

Use objdump to dump out that section and you have a raw binary file.

I do not mean a binary file.

[OSwhatever]

I do not mean a binary file, I know it as well as servel option like -nostdlib and -ffreestanding, what I what to express is that gcc always generate the file with advanced feature like .eh_frame section and glt(maybe in the future there will be more)，I can disable it by proper option, but problem is that, can I disable all of it totally and generate a pure executable file which include only enssential .text .data .rodata and .bss section

That's no problem. Create a linker script that only include the sections you want. Also after that you might want to strip the .elf file as well.

Code: Select all

ENTRY(_start)

PHDRS
{
	text PT_LOAD;
	data PT_LOAD;
}

SECTIONS
{
   . = 0x60000000;
   PROVIDE_HIDDEN(__text_start__ = .);
   .text : {
        *(.text*)
        *(.gnu.linkonce.t*)

        *(.rodata*)
        *(.gnu.linkonce.r*)

        PROVIDE_HIDDEN (__init_array_start = .);
        KEEP (*(SORT(.init_array.*)))
        KEEP (*(.init_array))
        PROVIDE_HIDDEN (__init_array_end = .);
    } :text 

    .data : {
        *(.data*)
        *(.gnu.linkonce.d*)
    } :data

   .bss : {
        PROVIDE_HIDDEN(__bss_start__ = .);
        *(.bss*)
        *(.gnu.linkonce.b*)
    } :data
    PROVIDE_HIDDEN(__bss_end__ = .);
}

This is just a small example and you can basically cherry pick the sections you want that suit your need.

[mallard]

In my understanding the problem is that there's a lot of stuff modern compilers put into executables and one needs to either understand all of it and properly handle it or find a sure way to simplify things to a manageable level. This is exacerbated by the fact that things keep changing (optimizations, options, sections change) and old recipes and shortcuts may stop working any time you pick up a newer version of the compiler (everybody seems to like new toys!).

That's obviously not true (you don't have to update your Linux/Windows/whatever every time there's a new compiler). As long as you stick to the specifications for the binary format you're using, the compiler used (and its options and optimisations) aren't important.

e.g. In order to load and run a statically-linked ELF executable, you only have to read and parse the file's program headers. The "sections" (.text, .data, etc.) aren't even used. You don't need to understand any of the "extra stuff" like the symbol table, debugging data, etc.

Sure, if you're using your own custom binary format or something equally esoteric, a less advanced compiler might be easier to understand and adapt. Otherwise, stick to the binary format's specifications, don't take "short cuts" and you'll be fine.

Still wondering what "zq" wants to achieve... If all that's needed is a smaller file, there's always the "strip" command...

[alexfru]

In my understanding the problem is that there's a lot of stuff modern compilers put into executables and one needs to either understand all of it and properly handle it or find a sure way to simplify things to a manageable level. This is exacerbated by the fact that things keep changing (optimizations, options, sections change) and old recipes and shortcuts may stop working any time you pick up a newer version of the compiler (everybody seems to like new toys!).

That's obviously not true (you don't have to update your Linux/Windows/whatever every time there's a new compiler). As long as you stick to the specifications for the binary format you're using, the compiler used (and its options and optimisations) aren't important.

It's not really about changing the OS. It's about changing the linker script, the startup code and other things that aren't governed (sufficiently or at all) by any standard or convention. I'm guessing, configuring and building the cross-compiler is among these things as well.

[iansjack]

I'd love to try Smaller C, and have a go at porting it to my OS, but, at present, it doesn't produce x86_64 code. That's an essential for me, and I suspect that a lot of people now target 64-bit code.

Do you have any plans to implement 64-bit support?

[LtG]

I'd love to try Smaller C, and have a go at porting it to my OS, but, at present, it doesn't produce x86_64 code. That's an essential for me, and I suspect that a lot of people now target 64-bit code.

Do you have any plans to implement 64-bit support?

I don't have any up to date info on Smaller C, but what would make it better? I'm not against it, as such, but if a "normal" (gcc/llvm) compiler is too hard, then osdev will be too hard, especially given that the Wiki gives pretty clear instructions on gcc cross build.

At the end of the day, if you want to control the output fully you will have create your own compiler, that has practical problems, which means everyone has to adjust to the output of the compiler they choose to use and then accept it or modify it as needed. I just don't see the benefit of a non-optimizing compiler, given that most (and gcc/llvm) compilers will allow you to disable optimizations anyway.

[iansjack]

Porting GCC to a new OS is by no means trivial. It's not like building a cross-compiler. It was relatively easy to port binutils, but I haven't managed GCC yet. So I would be interested in a simpler C compiler that produced 64-bit code.

Have you managed to port GCC to your OS?

[goku420]

I just don't see the benefit of a non-optimizing compiler, given that most (and gcc/llvm) compilers will allow you to disable optimizations anyway.

This is not true. Most compilers (including GCC) does not enable you to disable all optimizations. For example:

Code: Select all

gcc -Q -O0 --help=optimizers | grep enabled | wc

outputs 53 for me; and not all options have an "-fno" equivalent. Further, you can't really disable the optimizer itself (which is what Smaller C means when it says it is not an optimizing compiler) since it is part of the compiler backend that actually emits the bytecode. The catch is that Smaller C's lack of an optimizer is inherently what makes it difficult to port to other architectures.