OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 7:03 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 3:07 am 
Offline

Joined: Wed May 10, 2017 7:00 pm
Posts: 9
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


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 3:21 am 
Offline
Member
Member
User avatar

Joined: Tue Aug 02, 2016 1:52 pm
Posts: 286
Location: East Riding of Yorkshire, UK
You could use objcopy to pull out what you wanted after the build.

_________________
com.sun.java.swing.plaf.nimbus.InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState
Compiler Development Forum


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 3:27 am 
Offline

Joined: Wed May 10, 2017 7:00 pm
Posts: 9
matt11235 wrote:
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?


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 4:32 am 
Offline
Member
Member
User avatar

Joined: Sun Apr 05, 2015 3:15 pm
Posts: 31
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?

_________________
osdev project, goal is to run wasm as userspace: https://github.com/kwast-os/kwast


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 4:46 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Just create a custom linker script file that only includes the sections you want.


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 5:13 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
ndke wrote:
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.


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 5:21 am 
Offline
Member
Member

Joined: Mon Jul 05, 2010 4:15 pm
Posts: 595
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.


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 5:47 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Quote:
Use objdump to dump out that section and you have a raw binary file.

Quote:
I do not mean a binary file.


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 6:22 am 
Offline
Member
Member

Joined: Mon Jul 05, 2010 4:15 pm
Posts: 595
zq wrote:
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:
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.


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Thu Jun 01, 2017 6:54 am 
Offline
Member
Member

Joined: Tue May 13, 2014 3:02 am
Posts: 280
Location: Private, UK
alexfru wrote:
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...

_________________
Image


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Fri Jun 02, 2017 2:42 am 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 1108
mallard wrote:
alexfru wrote:
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.


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Fri Jun 02, 2017 3:56 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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?


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Fri Jun 02, 2017 12:29 pm 
Offline
Member
Member

Joined: Thu Aug 13, 2015 4:57 pm
Posts: 384
iansjack wrote:
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.


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Fri Jun 02, 2017 12:45 pm 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
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?


Top
 Profile  
 
 Post subject: Re: gcc option for pure executable file
PostPosted: Fri Jun 02, 2017 12:50 pm 
Offline
Member
Member

Joined: Wed Jul 10, 2013 9:11 am
Posts: 51
LtG wrote:
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:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 45 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group