On Tue, 3 Aug 2021 at 09:30, Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
> On Tue, Aug 3, 2021 at 12:55 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>> This one is still here:
>>
>> subprojects/libslirp/libslirp.so.0.3.1.p/src_arp_table.c.o: In
>> function `arp_table_add':
>> /mnt/nvmedisk/linaro/qemu-for-merges/build/clang/../../subprojects/libslirp/src/arp_table.c:51:
>> undefined reference to `__ubsan_handle_type_mismatch_v1'
>> /mnt/nvmedisk/linaro/qemu-for-merges/build/clang/../../subprojects/libslirp/src/arp_table.c:51:
>> undefined reference to `__ubsan_handle_type_mismatch_v1'
>>
>> when building the subprojects/libslirp/libslirp.so.0.3.1
>>
>> configure options:
>> '../../configure' '--cc=clang' '--cxx=clang++' '--enable-gtk'
>> '--extra-cflags=-fsanitize=undefined -fno-sanitize=shift-base
>> -Werror'
>
>
> I am not able to reproduce. Could you check the value of default_library for libslirp when you run "meson configure". It should be "static".
I never run "meson configure". I just run the QEMU "make".
Yes, here running "meson configure" after configure/make allows me to check what meson has actually recorded.
Are you testing by starting with a before-the-libslirp-merge
change QEMU, doing a build, then updating to the libslirp
changes, and then doing a 'make' without reconfigure or
'make clean' ? I suspect this is perhaps to do with it being
an incremental build.
I tested with the "make vm-build-ubuntu.amd64" setup I gave before, so it is a fresh build. Doing incremental build test is tedious, but I can give it a try.
>> This happens because (as noted in the clang documentation for the
>> sanitizer: https://clang.llvm.org/docs/AddressSanitizer.html)
>> when linking a shared library with the sanitizers, clang does not
>> link in the sanitizer runtime library. That library is linked in
>> with the executable, and the shared library's references to the
>> sanitizer runtime functions are satisfied that way. However
>> you/meson are building libslirp.so with -Wl,--no-undefined
>> so the link of the .so fails.
>> (This does not happen with gcc, because gcc chose to make the
>> default for sanitizers to be to link against a shared libasan,
>> not a static one, the reverse of clang's default.)
>>
>> What I don't understand is why we're building the .so at all.
>> I just tried a fresh build with
>> '../../configure' '--cc=clang' '--cxx=clang++' '--enable-gtk'
>> '--enable-sanitizers'
>> to check that telling configure (and possibly thus meson) about
>> the sanitizers more directly still demonstrated the problem:
>> but that sidesteps it because it never builds the .so.
>> My other build directories (the ones that do plain old gcc
>> builds with no sanitizer) seem to have built the .so file
>> as well, though, so this isn't related to either clang or to
>> the sanitizers -- meson just doesn't seem to be consistent
>> about what we build.
>>
>> A related meson bug:
>> https://github.com/mesonbuild/meson/issues/764
>> (which was closed by just making meson warn if you tell it
>> to both use --no-undefined (which is the default) and to use
>> the sanitizer.)
>>
>> The ideal fix seems to me to be to figure out why we're
>> building the libslirp .so and not do that.
>>
>> A simple fix/workaround would be to set "b_lundef = false" in
>> default_options in your meson.build (which will suppress the
>> -Wl,--no-undefined option). That does mean you won't get
>> any warnings if you accidentally make libslirp use a function
>> that is provided by the QEMU executable, I suppose.
>>
>
> What if you pass --extra-ldflags='-fsanitize=undefined' then?
-fsanitize=undefined is already in the ldflags. That doesn't
help because clang is still going to decide not to statically
link libasan and give an error because of -Wl,--noundefined.
Ok