Re: [PATCH 2/4] tools/nolibc: Fix strlcat() return code and size usage

[Rodrigo Campos]

On 2/13/24 00:16, Rodrigo Campos wrote:
> On 2/11/24 11:48, Willy Tarreau wrote:
> > The test inside the loop is going to make this not very efficient. Same
> > for the fact that we're measuring the length of src twice (once via
> > strlen, a second time through the loop). I've just had a look and it
> > compiles to 77 bytes at -Os. A simpler variant would consist in trying

What code are you compiling that uses strlcat?

I've tried dropping almost all the flags to leave only:
	-Os -nostdlib -lgcc

And I still don't see the 77 bytes.


> $ nm --size -t x test.o
>      0000000000000004 V errno
>      0000000000000006 t strlcat.constprop.0
>      0000000000000008 V _auxv
>      0000000000000008 V environ
>      000000000000000e W strlen
>      000000000000000f W _start
>      0000000000000018 W raise
>      000000000000001b W abort
>      000000000000004c T main
>      000000000000005a t u64toa_r.isra.0
>      0000000000000095 W _start_c
>      00000000000002a8 t printf
>
> How are you measuring it there?

btw, sorry for the late reply. I was on a flight that was rebooked, it 
took me some days to arrive. But I finally arrived and have internet now :)

The constprop seems to be some gcc optimization to simplify things.

I see what happens. The example I was compiling was left with size=0 (a 
leftover from when I was testing the code). That is very easy for gcc to 
optimize it all out. That is why it can make it so small.

If I compile the example from my original email, though, I still don't 
see the 77 bytes you mention. I see 31 in the nm output, that in decimal 
is 49 bytes.

Maybe tomorrow with some sleep after the long flight, I see what else is 
happening :)



Best,
Rodrigo