linux-kernel - Re: [PATCH v2 next 05/11] tools/nolibc/printf: Simplify __nolibc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260208122031.355dc213@pumpkin>
Date: Sun, 8 Feb 2026 12:20:31 +0000
From: David Laight <david.laight.linux@...il.com>
To: Willy Tarreau <w@....eu>
Cc: Thomas Weißschuh <linux@...ssschuh.net>,
 linux-kernel@...r.kernel.org, Cheng Li <lechain@...il.com>
Subject: Re: [PATCH v2 next 05/11] tools/nolibc/printf: Simplify
 __nolibc_printf()

On Sat, 7 Feb 2026 23:50:19 +0000
David Laight <david.laight.linux@...il.com> wrote:

> On Sat, 7 Feb 2026 21:05:42 +0100
> Willy Tarreau <w@....eu> wrote:
> 
> > On Fri, Feb 06, 2026 at 07:11:15PM +0000, david.laight.linux@...il.com wrote:  
> > > From: David Laight <david.laight.linux@...il.com>
> > > 
> > > Move the check for the length modifiers into the format processing
> > > between the field width and conversion specifier.
> > > This lets the loop be simplified and a 'fast scan' for a format start
> > > used.
> > > 
> > > If an error is detected (eg an invalid conversion specifier) then
> > > copy the invalid format to the output buffer.
> > > 
> > > Reduces code size by about 10% on x86-64.    
> > 
> > I'm surprised, because for me it's the opposite:
> > 
> >   $ size hello-patch*
> >      text    data     bss     dec     hex filename
> >      1859      48      24    1931     78b hello-patch1
> >      2071      48      24    2143     85f hello-patch2
> >      2091      48      24    2163     873 hello-patch3
> >      2422      48      24    2494     9be hello-patch4
> > 
> > The whole program grew by almost 16%, and that's a 30% increase since
> > the first patch. This is with gcc 15 -Oz. aarch64 however decreased by
> > 15 bytes since previous patch.
> > 
> > I have not figured what makes this change yet, I'm still digging.  
> 
> Running scripts/bloat-o-meter will give more detail.
> 
> > Willy  
> 
> I'm using gcc 12.2 and just running 'make O=xxx' for the test program.
> The object looks like what I'd expect, so might be -O2.
> 
> Is it constant folding the #defines.
> For me it generating the (1 << (c & 31)) & 0xxxxx as you might hope.

Further thoughts:

On some of the builds I've done gcc duplicated the code following an 'if'
into both the 'then' and 'else' clauses.
This isn't good for code size.
At one point I had an OPTIMIZER_HIDE_VAR(sign) before the u64to...()
block which did help, but that wasn't needed after the last patch or in
the patch sequence I posted.
(Maybe the 'if (v == 0) ...' block makes a difference.)

It might also be worth including the patch that changes u64to...()
before doing the size checks.
gcc should inline the wrappers - so it definitely changes the way the
code is generated.
To add octal support (for completeness) I'd explicitly generate the
three sets of constants in the printf() code and then call 
_nolibc_utoa_base().
The octal support is (approx):
	else if (_NOLIBC_PF_FLAGS_CONTAIN(ch_flag, 'o') {
		base = 8;
		recip = _NOLIBC_U64TOA_RECIP(8);
		if (_NOLIBC_PF_FLAGS_CONTAIN(ch_flag, '#' - 1)
			sign = '0';
	}
The last bit could be:
	sign = ((ch_flags >> n) & 1) * '0';
gcc might be persuaded to do that, but probably needs help.

	David