On Fri, Oct 16 2026, "Marcel Ziswiler" <[email protected]> wrote:
> Thanks Rasmus > > On Tue, 2026-10-13 at 11:38 +0200, Rasmus Villemoes wrote: >> On Tue, Oct 13 2026, "Rasmus Villemoes" <[email protected]> wrote: > > Yeah, overflow check sounded too easy, but I did try that for a start. Still > hangs. > > Then, I tried which one actually fails and it is strdup. > > If I just add size_t len = strlen(s); to the top of the old working strdup() > function, it also hangs. Strange. > > No, wait a minute, it just gets called with null strings, yes. > > But the new implementation should catch that as well. Strange. > > Somehow it does not like another level of indirection. But I haven't quite > figured out what exactly it is that > goes wrong. Will keep prodding it... Can you tell me the exact compiler/toolchain versions, and if using clang, can you try gcc (and vice versa of course). Is it a 32 bit or 64 bit target? Also, even if I can't read risc-v asm very well, can you paste the disassembly of the old and new strdup() functions. And the exact command line used to build lib/string.c, found in lib/.string.o.cmd . For both U-Boot proper and SPL (i.e. spl/lib/.string.o.cmd for the latter). Because playing around with this code in godbolt I can definitely see the compiler eliding the NULL checks in some cases, but that also applies to the old implementation, i.e. I see an unconditional call of strlen(). But I assume godbolt's toolchain always sees userspace <string.h> which has __attribute__((nonnull(1))) on strdup(), and we don't. But it can also be the compiler which "knows" that strdup() has a non-null contract, i.e. the compiler might have a built-in prototype for strdup(). Anyway, there are too many variables in play here, so I'd like to narrow it down a bit to your exact setup. Rasmus
