gcc option for pure executable file

[zq]

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.

just as you understand.
in osdev, we should pay attention to all the sections generated by gcc, for example, if I got `eh_frame` section, I should search the Internet and then find I can just simply discard it or turn it of by gcc option.
But what about tomorrow, if I get `fh_frame`, `gh_frame`, `dh_frame`, which can be discard, which can need to disable by `gcc -fno-foo-bar` option? even worse, I compile my old source with new version of gcc and it generate a section `.sext`(something like `.text` and needed by .text) and just discard it becouse by `objcopy` I do not copy it at all, I will get a crash

[goku420]

just as you understand.
in osdev, we should pay attention to all the sections generated by gcc, for example, if I got `eh_frame` section, I should search the Internet and then find I can just simply discard it or turn it of by gcc option.
But what about tomorrow, if I get `fh_frame`, `gh_frame`, `dh_frame`, which can be discard, which can need to disable by `gcc -fno-foo-bar` option? even worse, I compile my old source with new version of gcc and it generate a section `.sext`(something like `.text` and needed by .text) and just discard it becouse by `objcopy` I do not copy it at all, I will get a crash

You can't actually discard .eh_frame, at least not for the kernel binary without getting an error. GCC expects this to be present even if you disable exceptions/rtti since the .eh_frame is multi-purpose. You might get luck by mucking around with flags like -fno-asychronous-wind-tables or strip (guaranteed to cause more problems than it solves) but really you should just handle it instead of trying to remove it.

My magic ball tells me that you are getting a crash and blaming it on .eh_frame; removing it won't make the crash go away.

[LtG]

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?

I haven't attempted to port GCC, so I don't know how easy or hard it would be. I don't have an IDE either, so compiling isn't really that important for me at this point.

For me the whole point is to build something better, so when/if I do get there, I can't really use any compiler that doesn't do optimization since that wouldn't be better. I would accept non-optimization initially, but if that were the case then it would almost certainly be because I was making my own compiler. If I'm going to use an existing compiler then I'm likely to pick a compiler that's widely used and has decent/good optimizations. I haven't done any research into this part, but gut feeling is that it would be either GCC or LLVM. As I understand it the code base for LLVM is "better", but I have no idea if that has any impact on it being easier to port.

Out of curiosity, what issues did you have with porting GCC? The dependencies (libraries)?

[zq]

You can't actually discard .eh_frame, at least not for the kernel binary without getting an error. GCC expects this to be present even if you disable exceptions/rtti since the .eh_frame is multi-purpose. You might get luck by mucking around with flags like -fno-asychronous-wind-tables or strip (guaranteed to cause more problems than it solves) but really you should just handle it instead of trying to remove it.

My magic ball tells me that you are getting a crash and blaming it on .eh_frame; removing it won't make the crash go away.

actualy I didn't get a crash, also I find in linux kernrl linker script it discard .eh_frame

[LtG]

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.

Good point, something to keep in mind, but not really relevant to what I was saying. My point wasn't that you can necessarily disable all optimizations, I'm not sure you can even make the distinction fully what is and isn't an optimization, since compilers can do pretty much anything they want with the input C code, so long as they follow a few rules.

My point was that practically speaking, given the choice of two compilers, one which doesn't optimize and one which does but allows (to a reasonable extent) to also disable them, why would you want the non-optimizing one? Iansjack made a good point about self-hosting, that may be valid. I don't know if GCC is hard to port and Smaller-C is easy to port.

However, at least for me porting Smaller-C would be useless since it would defeat the whole point. Until some compiler is ported I will have to cross-compile, and I'm doing so with an optimizing compiler. Once I had Smaller-C ported and started to compile my OS _on_ my OS using Smaller-C I immediately get bloated (non-optimized) binaries, which I assume will hurt performance (I don't know how much), which means I probably continue to cross-compile on some other OS, leaving ported Smaller-C unused, thus not useful for me.

Though I am curious if GCC is really hard to port, whether LLVM would be easier, and if Smaller-C is significantly easier that the former two..

[alexfru]

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?

Not in the near future. It doesn't support any 64-bit primitive types, IOW, types that are twice the size of int / machine word, which is the same reason why the tiny and small memory models don't have 32-bit primitive types and why there's no double in other models. Everything is machine word or smaller. I don't think you want a 64-bit int and no way to support a 32-bit one (8-bit and 16-bit already have their type names: char and short and there's no medium/semi/half int in the language).

Also, what about the assembler? Do you have any ported? Smaller C comes without an assembler of its own and relies on NASM/YASM or FASM.
EDIT: Oh, you seem to have ported binutils. In this case some syntax adjustments (or conversion?) will be needed for the GNU assembler.

[alexfru]

The catch is that Smaller C's lack of an optimizer is inherently what makes it difficult to port to other architectures.

How so?

[iansjack]

Not in the near future.

OK. Thanks for that.

I'll persist with gcc.