qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL v2 00/37] Linux user for 5.0 patches


From: Laurent Vivier
Subject: Re: [PULL v2 00/37] Linux user for 5.0 patches
Date: Wed, 18 Mar 2020 20:58:29 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

Le 18/03/2020 à 20:46, Richard Henderson a écrit :
> On 3/18/20 6:57 AM, Peter Maydell wrote:
>> My set of "run ls for various architectures" linux-user tests
>> https://people.linaro.org/~peter.maydell/linux-user-test-pmm-20200114.tgz
>> fails with this pullreq:
>>
>> e104462:bionic:linux-user-test-0.3$
>> /home/petmay01/linaro/qemu-for-merges/build/all-linux-static/x86_64-linux-user/qemu-x86_64
>> -L ./gnemul/qemu-x86_64 x86_64/ls -l dummyfile
>> qemu: 0x40008117e9: unhandled CPU exception 0x101 - aborting
> 
> 
> I replicated this on aarch64 host, with an existing build tree and merging in
> the pull request.  It does not occur when building the same merged tree from
> scratch.
> 
> I have no idea what the reason for this is.  Laurent suggested a file in the
> build tree that is shadowed by one in the source tree, but to me that makes no
> sense for this case:
> 
> It's target/i386/cpu.h that defines EXCP_SYSCALL (renumbered in this series
> from 0x100 to 0x101), which is not in the build tree.  It is
> linux-user/i386/cpu_loop.c that consumes EXCP_SYSCALL, and it is also not in
> the build tree.
> 
> However, from the error message above, it's clear that cpu_loop.o has not been
> rebuilt properly.
> 

In the series merged here syscall_nr.h are moved from source directory
to build directory.

The include path of the files is based on the dependecy files (*.d), and
to force the update of this path PATCH 13 removes all the .d files that
have a dependecy on the syscall_nr.h file in the source path.

This is added in configure:

--- a/configure
+++ b/configure
@@ -1887,6 +1887,17 @@ fi
 # Remove old dependency files to make sure that they get properly
regenerated
 rm -f */config-devices.mak.d

+# Remove syscall_nr.h to be sure they will be regenerated in the build
+# directory, not in the source directory
+for arch in ; 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
+    find . -name "*.d" \
+           -exec grep -q
"${source_path}/linux-user/${arch}/syscall_nr.h" {} \; \
+           -exec rm {} \;
+done
+
 if test -z "$python"
 then
     error_exit "Python not found. Use --python=/path/to/python"

For the use of the dependency see for instance PATCH 14:

--- a/configure
+++ b/configure
@@ -1889,7 +1889,7 @@ rm -f */config-devices.mak.d

 # Remove syscall_nr.h to be sure they will be regenerated in the build
 # directory, not in the source directory
-for arch in ; do
+for arch in alpha ; 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 file
+++ b/linux-user/alpha/Makefile.objs
@@ -0,0 +1,5 @@
+generated-files-y += linux-user/alpha/syscall_nr.h
+
+syshdr := $(SRC_PATH)/linux-user/alpha/syscallhdr.sh
+%/syscall_nr.h: $(SRC_PATH)/linux-user/alpha/syscall.tbl $(syshdr)
+       $(call quiet-command, sh $(syshdr) $< $@ 
$(TARGET_SYSTBL_ABI),"GEN","$@")


%/syscall_nr.h is expanded with the absolute path found in the .d file.

Perhaps it removes a dependency that should trigger the rebuild of
cpu_loop.o?

Thanks,
Laurent



reply via email to

[Prev in Thread] Current Thread [Next in Thread]