Removing RTTI from binaries
Mike via D.gnu
d.gnu at puremagic.com
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
> 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
Without the sed hack, my binary is 450k. With the sed hack it's
The binary seems to fill .rodata with the TypeInfo.name 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 TypeInfo.name 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