Received-SPF: pass (google.com: domain of linux-kernel+bounces-40181-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
From: Rodrigo Campos <rodrigo@sdfg.com.ar>
To: Willy Tarreau <w@1wt.eu>,
	=?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= <linux@weissschuh.net>
Cc: linux-kernel@vger.kernel.org,
	Rodrigo Campos <rodrigo@sdfg.com.ar>
Subject: [PATCH 0/1] tools/nolibc/string: export strlen()
Date: Fri, 26 Jan 2024 15:24:10 +0100
Message-ID: <20240126142411.22972-1-rodrigo@sdfg.com.ar>
Precedence: bulk
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit

Hi, while using nolibc on debian testing, I found that compilation fails when using strlcat().

The compilation fails with:

            cc -fno-asynchronous-unwind-tables -fno-ident -s -Os -nostdlib -lgcc  -static -o test test.c
            /usr/bin/ld: /tmp/cccIasKL.o: in function `main':
            test.c:(.text.startup+0x1e): undefined reference to `strlen'
            collect2: error: ld returned 1 exit status

This is using debian testing, with gcc 13.2.0.

A small repro case that fails with this error on debian is:

	int main(void) {
		char dst[6] = "12";
		char *src = "abc";
		strlcat(dst, src, 6);
	
		printf("dst is: %s\n", dst);
	
		return 0;
	}

Please note that this code is not using strlen() and strlcat() doesn't seems to use it either.

First I noted that removing the attribute unused in strlen(), the compilation worked fine. And then
I noticied that other functions had the attribute weak, a custom section and export the function.

In particular, what happens here seems to be the same as in commit "tools/nolibc/string: export memset() and
memmove()" (8d304a374023), as removing the -Os or adding the -ffreestanding seem to fix the issue.
So, I did the same as that commit, for strlen().

However, I'm not 100% confident on how to check that this is done by the compiler to later replace
it and provide a builtin. I'm not sure how that was verified for commit 8d304a374023, but if you let
me know, I can verify it too.

What do you think?


As a side note, it seems strlcat()/strlcpy() fail to set the terminating null byte on some cases,
and the return code is not always the same as when using libbsd. It seems to be only on "error"
cases, and not sure if it's worth fixing all/some of those cases.

Let me know if you think it is worth adding some _simple_ patches (I don't think it is worth fixing
all the cases, the code is to fix all of the cases is probably not nice and not worth it).


Best,
Rodrigo

---


Rodrigo Campos (1):
  tools/nolibc/string: export strlen()

 tools/include/nolibc/string.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.43.0