gem5 syscall emulation se.py on MinorCPU fails after clone in multithread example with "panic: Page table fault when accessing virtual address 0"

[cirosantilli]

Upstream report: https://gem5.atlassian.net/browse/GEM5-630

Just after clone the address 0 is accessed before any new instruction logs get printed. This suggests that the new thread is not properly initialized, and tries to read its instruction from address 0.

Originally fixed at: https://gem5-review.googlesource.com/c/public/gem5/+/8182 but later reverted at https://gem5-review.googlesource.com/c/public/gem5/+/18604 because it broke some regressions.

Reproducible with:

./run --arch aarch64 --cpus 2 --emulator gem5 --static \
  --userland userland/posix/pthread_self.c --userland-args 1 \
  --gem5-worktree master -- --cpu-type MinorCPU --caches

with gem5 at 2dc4b9d95a156030e9b7ac44ffbdbf9bdacc5944 and LKMC 5b7094f.

It works if we run with the fix rereverted.

This is a minor specific problem, it did not happen on DerivO3CPU or AtomicSimpleCPU with identical options.

There has however been a report on DerivO3CPU, which does not fail on any clone, but has the same failure message under very specific settings: https://www.mail-archive.com/gem5-users@gem5.org/msg17032.html Adapted command without Ruby at gem5 1fd1d2ed267757e4ea50faeaf9c6d784aa1f0049

./run -aA -eg --gem5-worktree master --userland data/gem5/master/tests/test-progs/pthread/bin.aarch64/test_pthread_mutex --cpus 16 --  --cpu-type DerivO3CPU --caches --l1d_assoc=4 --l1i_assoc=4 --l2_assoc=16 --cacheline_size 64 --l1i_size 64kB --l1d_size 64kB --l2_size 4MB

I was unable however to create a non C++ reproduction, and threads + C++ + static is known to be buggy: https://stackoverflow.com/questions/35116327/when-g-static-link-pthread-cause-segmentation-fault-why | https://stackoverflow.com/questions/58848694/gcc-whole-archive-recipe-for-static-linking-to-pthread-stopped-working-in-rec The same command with QEMU does work however with that exact same statically linked executable.