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

From: Rodrigo Campos
Date: Tue Feb 13 2024 - 00:28:05 EST

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 :)