"GOT", but the "O" is a cute, smiling pufferfish. Index | Thread | Search

From:
Stefan Sperling <stsp@stsp.name>
Subject:
Re: chores; move patch send/recv to privsep.c
To:
Omar Polo <op@omarpolo.com>
Cc:
gameoftrees@openbsd.org
Date:
Tue, 5 Jul 2022 10:13:48 +0200

Download raw body.

Thread
On Tue, Jul 05, 2022 at 09:55:51AM +0200, Omar Polo wrote:
> agreed.  if we want to have the libexec helpers even more small maybe we
> could split privsep.c into multiple privsep_*.c files, so that the
> libexec helpers can link only to the bits they actually need?

Maybe. For now, keeping code that is only used by one libexec helper
in the .c file of this helper contributes to the end goal of having
minimal helper binaries in libexec.

> I did a quick search and just for giggles tried to build got-read-patch
> with LTO.  It significantly reduces the sizes of the helpers (patch went
> from 229K to 54K, and once stripped down to 30K) and seemed to strip out
> all the unused functions, but admittedly is something we can't use.  Was
> fun to try thought, last time i played with -flto i had clang dying of
> OOM :)
> 
> 	% ls -lah got-read-patch
> 	-r-xr-xr-x  1 op  op  54.3K Jul  5 09:54 got-read-patch*
> 	% nm got-read-patch | grep got_privsep
> 	00006b90 t got_privsep_flush_imsg
> 	00006610 t got_privsep_recv_imsg
> 	000069e0 t got_privsep_send_error

Oh, that is nice. This could help us to see the groups of functions
needed by each helper. Once we have a grouping, we could move things
around to ensure that the smallest required subset will be linked,
regardless of toolchain tricks like LTO.

It would not hurt to do such cleanup on a semi-regular basis. But we
can also do such work when most of Got is "done", i.e. before we finally
ship a 1.0 release that comes with backwards compatibility promises.
There is little reason to do a lot of such work now, unless you are curious.