Removing dead code (GCC/LD)

[AndrewAPrice]

I have made a rather huge user library, and when I statically link my programs to it each one becomes at least 500kb in size. The thing is, each program only uses a very small subset of the library, so that's a good 400kb of dead code. This becomes a problem when I try to fit my OS onto a floppy image.

I'm using GCC (and GDC) for compiling, and LD for linking. I'm wondering how (if) I can enable dead code elimination, and would it be a linker switch (since only the linker has an overview of the entire project)?

[JackScott]

How large are the individual object (and thus C) files making up the library? IIRC, the linker can only include the whole .o file, not a subset of it. So the smaller the object file (such as making the C file only have one function in it), the less the linker has to include.

I'll wait for Solar to come along and confirm before I would be confident in this though.

[Solar]

I'll wait for Solar to come along and confirm before I would be confident in this though.

Confirmed.

[JackScott]

Confirmed.

*pulls air, tennis player style*

[AndrewAPrice]

Thanks, I just found --strip-all and --gc-sections. Instantly it stripped my kernel from 412kb to 64kb without corrupting anything so far!

[Solar]

--strip-all is a completely different feature - it removes symbol (i.e., debug) information from your binary.

[jal]

--strip-all is a completely different feature - it removes symbol (i.e., debug) information from your binary.

lol

OT: I believe the Turbo Pascal linker did not include functions and procedures include in modules that weren't used. I've always failed to understand why a multiple-pass linker could not do the same for C, but perhaps that's just my limited indepth knowledge...


JAL

[Creature]

--strip-all is a completely different feature - it removes symbol (i.e., debug) information from your binary.

I was wondering if debug information is even important in your kernel if you're not attempting to use GDB or something?

[qw]

OT: I believe the Turbo Pascal linker did not include functions and procedures include in modules that weren't used. I've always failed to understand why a multiple-pass linker could not do the same for C, but perhaps that's just my limited indepth knowledge...

It indeed could. I still fail to understand what analysis technique does LD miss that it cannot do the same. Need to look at a way Pascal units are organized, probably they contain way more metadata than ELF .o files.

There is some information about the TPU file format on wotsit.org.

[jal]

It indeed could. I still fail to understand what analysis technique does LD miss that it cannot do the same. Need to look at a way Pascal units are organized, probably they contain way more metadata than ELF .o files.

Well, since Pascal has the 'define first, use later' policy, there's no way to use a procedure before it is defined. And since declaring happens in the header of the module file, and the implementation necessarily in the same module, once you have included a module, you know the function exists. So TP (or any Pascal compiler) can issue unknown reference errors while compiling instead of linking. This as opposed to C, which allows declaration without definition, so the linker has to do all the works. ld would need at least one additional pass to be able to exclude certain code, but that should be relatively easy, compared to all the other complications of linking.


JAL

[JamesM]

--strip-all is a completely different feature - it removes symbol (i.e., debug) information from your binary.

I was wondering if debug information is even important in your kernel if you're not attempting to use GDB or something?

I use the DWARF debug_frames section to implement cross-platform backtracing.

[JohnnyTheDon]

--strip-all is a completely different feature - it removes symbol (i.e., debug) information from your binary.

I was wondering if debug information is even important in your kernel if you're not attempting to use GDB or something?

Debugging isn't the only use for symbols. If you use the symbol table for locating functions (for example in a shared library) you need symbols. IIRC '--strip-debug' will remove your debug info and leave the symbol table intact. I've found that gcc/ld export WAY too many symbols though, which is important if you are making something closed source and you don't want people knowing the names and locations of all you functions.

[leledumbo]

Free Pascal produces assembly files for each functions / procedures and variables, assembled them one by one so that each has its own .o file, then use ar to create a static lib. So, when calling ld it can simulate the smartlinking (or dead code elimination) technique.

This applies to systems where the internal linker not yet exists. The internal linker (currently, only Win32/64 has it) already knows how to smartlink, thus removing the need to create static lib with a bunch of .o files.