Hi On Tue, Aug 3, 2021 at 1:09 PM Peter Maydell <peter.mayd...@linaro.org> wrote:
> On Tue, 3 Aug 2021 at 09:30, Marc-André Lureau > <marcandre.lur...@gmail.com> wrote: > > On Tue, Aug 3, 2021 at 12:55 AM Peter Maydell <peter.mayd...@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 -- Marc-André Lureau
