`sstrip` vs `strip --strip-all` analysis

There has been some discussion since the adoption of super-strip (sstrip) was selected as the default stripping method over standard strip --strip-all. I wanted to analyze the space-gains by sstrip and see if those gains justifies its adoption.

Super-Strip Description:

Super-strip is a stripping utility that truncates the entire section header table from an elf binary. It is slightly more effective than strip --strip-all at reducing the size of a binary, but the cost is that it leaves shared libraries in a state that they cannot subsequently be linked against. There are no known negative consequences to using sstrip on normal executable binaries. OpenWrt builds recently switched from using strip --strip-all to sstrip as the default stripping mechanism.

I analyzed a build of today's MASTER for a Mediatek mt7622 (BPI-R64 device) using the stock configuration file for that platform. The configuration file was modified only to select either:

  • Global Build Setting -> Binary stripping method sstrip -z (default)
  • Global Build Setting -> Binary stripping method strip --strip-all
Methodology Note

Methodology Note: A relatively recent, but stable 64-bit device was chosen in order to maximize the file sizes and thus magnify the the differences, if any, between sstrip and strip --strip-all.

Results:

Strip Method Total Build Size Shared Library Size
strip --strip-all 13,596,494b 3,727,343b
sstrip 13,450,612b 3,683,827b
Savings: 145,882 / 142.5Kib 43516 / 42.5Kib

Analysis:
Using sstrip over strip --strip-all nets a gain of 142.5Kib on a build for a 64-bit device. This is approximately 1.1%. However, the use of sstrip on normal binaries is not at all controversial. Only its use on shared libraries has a negative effect. The reduction in size of a distribution that uses sstrip for normal binaries and strip --strip-all for shared libraries is 42.5Kib, or a reduction of 0.3%.

Why only the base distribution was consideredy

Why only the base distribution was considered: The above numbers consider effect of sstrip vs strip --stripall only on the base installation, and not added packages. This is because the availability of external storage for even cheap, commodity devices is almost universal. It is likely that anyone who wants to install any significant number of external packages will likely be using some sort of extroot, or additional space, in which case the size of added packages is almost entirely moot.

Even for those routers without any sort of external storage, the space-savings of an additional 0.3% of using sstrip is unlikely to be the determining factor on what can or can't be installed.

Assessment:
It is my opinion that eliminating the use of sstrip over strip --stripall is a very low cost to pay for the added ability for all users to be able to use shared libraries in the normal manner. It could be done in the following ways:

  1. As an OpenWrt-wide global change
    Implementation Cost: A simple change in the config project-wide. Trivial.
    Usage Cost: An increase of 1% in overall distribution size may have to be offset in the case of some select very small routers.
  2. On a per-platform basis
    Implementation Cost: A simple change in the config on platforms which each config maintainer determines there is ample storage.
    Usage Cost: Nothing
  3. As an OpenWrt-wide global change only for shared libraries
    Implementation Cost: Small change in the build system, perhaps three or four hours work for one volunteer knowledgable in the build system. If implemented well (ie: splitting the strip config into two, one for binaries, one for libraries) then usage cost is further reduced.
    Usage Cost: Very small - an increase of 0.3% (max of a few tens of kilobytes) in build size - even the very smallest routers should be able to absorb that. If implemented correctly, then the very smallest devices can still retain sstrip as the default in their configs.
1 Like