I noticed a lot of not-obviously-used stuff brought in from various libraries and wanted to nuke some of the unneeded things. Step 1 was trying to compile the libraries with the option, which didn't quite fly... it looks like ghc-asm is the primary sufferer, and I'm not sure the compiler option is needed...

Yes, indeed you could do this in ghc-asm. But don't forget the native code generator too...

-split-objs I didn't really realize was there. I see (tracing through ghc5, whatever debian's latest shipping version is):

ghc/compiler/main/DriverFlags.hs:250 , ( "split-objs" , NoArg (if can_split then do writeIORef v_Split_object_files True add v_Opt_C "-fglobalise-toplev-name s" else hPutStrLn stderr "warning: don't know how to split \ \object files on this architecture" ) )

-split-objs has to go to some trouble to make more symbols global so that they can still be resolved after the assembler file has been split into chunks. This is one rather ugly hack that it would be nice to get rid of.

Then in ghc/driver/split/ghc-split.lprl:287 (there's actually one per arch):

# strip the marker

$str =~ s/(\.text\n\t\.align .(,0x90)?\n)\.globl\s+.*_?__stg_split_marker.*\ n/$1/; $str =~ s/(\t\.align .(,0x90)?\n)\.globl\s+.*_?__stg_split_marker.*\n/$1/;

...

Yes, this is all particularly horrible too. The splitter has to go to some trouble to make sure that "local constants" (strings and the like) get duplicated in each assembler chunk that refers to them, subverting the commoning up of constants that gcc does.

So to me it looks feasible to figure out who's fooling with these things, though it's probably not necessary to do any of this within the compiler except for whatever might circumvent ghc-asm, if anything.

At any rate, I am finding the amount of unused code/data linked into the generated executables significant... for instance, in a non- concurrent program:

080a1c64 D MVar_modifyMVarzu_closure 0805aeb8 T MVar_modifyMVarzu_entry 0805aece T MVar_modifyMVarzu_fast3 0805aeb8 T MVar_modifyMVarzu_info

The IO library requires MVars (it's thread-safe) so most programs will have some MVar bits linked in. I'm not sure why modifyMVar in particular is being included though.

... and as it's a 9-line script to mangle patches, it's certainly not using this:

0805b140 T __stginit_PosixDB

The idea with -ffunction-sections or brewing up an equivalent is to build the libraries with it so when the final executable is linked, it imports only the code and statically-allocated data it uses from them.

Ok, I'm convinced :) Let us know if you need any more help. Cheers, Simon