Re: [Valgrind-developers] missing -Wformat warnings

[Florian K. <fl...@ei...>]

On 07.05.25 21:58, Paul Floyd via Valgrind-developers wrote:
>>
>> I noticed that the presence of -fno-builtin suppresses -Wformat warnings.
>> First I thought this to be a GCC bug but it is not.
> 
> Strange. I don't see any relationship between the two.
> 

The -fno-builtin gcc docs are not very precise.. I believe that
they mean C/C++/whatever library functions when they talk about
built-in functions (other than those beginning with __builtin_).

-fno-builtin then means: when you encounter a function that has the same
name as a built-in function, forget everything you know about that function.
That includes functions attributes. And without __attribute__((format...))
being present there will be no -Wformat warnings.

<quote>
For example, warnings are given with '-Wformat' for bad calls to
'printf' when 'printf' is built in.
</quote>


> No. On openSUSE Leap 15.6 amd64 with GCC 14.2 I get link errors. We would need 
> to provide a 'strlen' implementation at least for amd64 Linux.
> 
> Here are the errors:
> 
> ../coregrind/link_tool_exe_linux 0x58000000 gcc-14     -o memcheck-amd64-linux  
> -m64 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith 
> -Wstrict-prototypes -Wmissing-declarations -Wno-unused-result -Wcast-align 
> -Wcast-qual -Wwrite-strings -Wempty-body -Wformat -Wformat-signedness 
> -Wformat-security -Wignored-qualifiers -Wmissing-parameter-type -Wlogical-op 
> -Wenum-conversion -Wimplicit-fallthrough=2 -Wold-style-declaration 
> -finline-functions -fno-stack-protector -fno-strict-aliasing   
> -fomit-frame-pointer -O2 -static -nodefaultlibs -nostartfiles -u _start  -m64 
> memcheck_amd64_linux-mc_leakcheck.o memcheck_amd64_linux-mc_malloc_wrappers.o 
> memcheck_amd64_linux-mc_main.o memcheck_amd64_linux-mc_main_asm.o 
> memcheck_amd64_linux-mc_translate.o memcheck_amd64_linux-mc_machine.o 
> memcheck_amd64_linux-mc_errors.o ../coregrind/libcoregrind-amd64-linux.a 
> ../VEX/libvex-amd64-linux.a -lgcc ../coregrind/libgcc-sup-amd64-linux.a
> /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: 
> ../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_libcbase.o): in function `vgPlain_strlen':
> /home/paulf/scratch/valgrind/coregrind/m_libcbase.c:263:(.text+0xc8e): undefined 
> reference to `strlen'

So GCC figues out that the definition of VG_(strlen) is semantically equivalent 
to the 'strlen' built-in function.

<quote>
In addition, when a function is recognized as a built-in function, GCC may
use information about that function to warn about problems with calls to
that function, or to generate more efficient code,
</quote>

So it makes the VG_(strlen) body to be a call to strlen. That is fine as
long as you're linking to libc which we don't. But GCC does not know
that when compiling and by default targets a hosted environment.
Adding -ffreestanding won't help as it implies -fno-builtin.

I am wondering whether adding -nodefaultlibs to the compile flags helps.

<quote>
'-nodefaultlibs'
      Do not use the standard system libraries when linking.  ...
</quote>

If GCC still adds a dependency on a library function that I'm telling it won't 
be there - that would be quite odd...

Could you give that a try? Or may be change VG_(strlen) to return 
__builtin_strlen(str) ?

Thanks,
   Florian