[Bug 1883560] Re: mips linux-user builds occasionly crash randomly only to be fixed by a full clean re-build

[Laurent Vivier]

syscall_nr.h is generated from syscall_n32.tbl and syscall_n64.tbl, so
it should be under your build directory, not the source directory.

But if you did a build before the change, the dependency file .d will
store a path in the src dir and the new file will not be generated in
the build dir but in the previous place.

linux-user/mips64/Makefile.objs:

ifeq ($(TARGET_SYSTBL_ABI),n32)
%/syscall_nr.h: $(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)/syscall_n32.tbl 
$(syshdr)
        $(call quiet-command, sh $(syshdr) $< $@ n32 "" 6000,"GEN","$@")
endif
ifeq ($(TARGET_SYSTBL_ABI),n64)
%/syscall_nr.h: $(SRC_PATH)/linux-user/$(TARGET_ABI_DIR)/syscall_n64.tbl 
$(syshdr)
        $(call quiet-command, sh $(syshdr) $< $@ n64 "" 5000,"GEN","$@")
endif

Normally this is cleaned up by the configure with:

for arch in alpha hppa m68k xtensa sh4 microblaze arm ppc s390x sparc sparc64 \
    i386 x86_64 mips mips64 ; do
    # remove the file if it has been generated in the source directory
    rm -f "${source_path}/linux-user/${arch}/syscall_nr.h"
    # remove the dependency files
    for target in ${arch}*-linux-user ; do
        test -d "${target}" && find "${target}" -type f -name "*.d" \
             -exec grep -q "${source_path}/linux-user/${arch}/syscall_nr.h" {} 
\; \
             -print | while read file ; do rm "${file}" "${file%.d}.o" ; done
    done
don

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1883560

Title:
  mips linux-user builds occasionly crash randomly only to be fixed by a
  full clean re-build

Status in QEMU:
  New

Bug description:
  From time to time I find check-tcg crashes with a one of the MIPS
  binaries. The last time it crashed was running the test:

    ./mips64el-linux-user/qemu-mips64el ./tests/tcg/mips64el-linux-
  user/threadcount

  Inevitably after some time noodling around wondering what could be
  causing this weird behaviour I wonder if it is a build issue. I wipe
  all the mips* build directories, re-run configure and re-build and
  voila problem goes away.

  It seems there must be some sort of build artefact which isn't being
  properly re-generated on a build update which causes weird problems.
  Additional data point if I:

    rm -rf mips64el-linux-user
    ../../configure
    make

  then I see failures in mip32 builds - eg:

      GEN     mipsn32el-linux-user/config-target.h
    In file included from /home/alex/lsrc/qemu.git/linux-user/syscall_defs.h:10,
                     from /home/alex/lsrc/qemu.git/linux-user/qemu.h:16,
                     from /home/alex/lsrc/qemu.git/linux-user/linuxload.c:5:
    /home/alex/lsrc/qemu.git/linux-user/mips64/syscall_nr.h:1: error: 
unterminated #ifndef
     #ifndef LINUX_USER_MIPS64_SYSCALL_NR_H

    make[1]: *** [/home/alex/lsrc/qemu.git/rules.mak:69: 
linux-user/linuxload.o] Error 1
    make[1]: *** Waiting for unfinished jobs....

  which implies there is a cross dependency between different targets
  somewhere. If I executed:

    rm -rf mips*

  before re-configuring and re-building then everything works again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1883560/+subscriptions