Removing RTTI from binaries

Mike via D.gnu d.gnu at
Sun May 10 06:46:03 PDT 2015

On Sunday, 10 May 2015 at 13:20:42 UTC, Iain Buclaw wrote:
> Not sure what you're using to build, but it seems reliant on
> -ffunction-sections -fdata-sections -fmerge-constants - or at 
> least
> the latter two of those options.
> Did you try the minimum test in the PR?

I'm using the cross-compiler built with this script:

I compiled with -ffunction-sections -fdata-sections 
-fmerge-constants, and a few other variants.  I link with 

For a test program, I'm using my LCD demo here:

The only way I can get a minimal binary is to compile to 
assembly, use this sed hack 
to put strings into their own section, and then compile the 
modified assembly.

Without the sed hack, my binary is 450k.  With the sed hack it's 

The binary seems to fill .rodata with the field.  
Here's a small sample of what that looks like in the binary:

  801fa00 6572616c 2e526567 69737465 72212830  eral.Register!(0
  801fa10 2c206361 73742841 63636573 73293729  , cast(Access)7)
  801fa20 2e526567 69737465 722e4269 74212831  .Register.Bit!(1
  801fa30 312c2063 61737428 4d757461 62696c69  1, cast(Mutabili
  801fa40 74792932 292e4269 74000000 6d6d696f  ty)2).Bit...mmio
  801fa50 2e506572 69706865 72616c21 28414842  .Peripheral!(AHB
  801fa60 312c2031 35333630 292e5065 72697068  1, 15360).Periph

Those are the types instantiated with my mmio template library.  
Here's a sample:

It appears the field is not put into its own 
section even though I compile with -fdata-sections.  I guess I'll 
have to inspect the binary compiled with the patch to see what's 


More information about the D.gnu mailing list