Message ID | 20200317155116.1227513-1-laurent@vivier.eu |
---|---|
State | New |
Headers | show |
On Tue, 17 Mar 2020 at 16:05, Laurent Vivier <laurent@vivier.eu> wrote: > > The following changes since commit 373c7068dd610e97f0b551b5a6d0a27cd6da4506: > > qemu.nsi: Install Sphinx documentation (2020-03-09 16:45:00 +0000) > > are available in the Git repository at: > > git://github.com/vivier/qemu.git tags/linux-user-for-5.0-pull-request > > for you to fetch changes up to 85db278520fd800d8e8de9a527c8f0e1a962055e: > > linux-user, openrisc: sync syscall numbers with kernel v5.5 (2020-03-17 16:36:17 +0100) > > ---------------------------------------------------------------- > update syscall numbers to linux 5.5 (with scripts) > add futex_time64/clock_gettime64/clock_settime64 > add AT_EXECFN > Emulate x86_64 vsyscalls > > v2: guard copy_to_user_timezone() with TARGET_NR_gettimeofday > remove "Support futex_time64" patch > guard sys_futex with TARGET_NR_exit > > ---------------------------------------------------------------- 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 RAX=000000000000003f RBX=000000006ffffe34 RCX=00000040008004c0 RDX=0000004000813180 RSI=0000000000000064 RDI=00000040007ffff0 RBP=000000006fffff40 RSP=00000040007fffe8 R8 =0000000000000000 R9 =00000040008004fe R10=0000004000801a18 R11=0000004000801260 R12=0000004000800240 R13=0000000000000008 R14=0000000000400040 R15=00000040008032d0 RIP=00000040008117e9 RFL=00000246 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES =0000 0000000000000000 00000000 00000000 CS =0033 0000000000000000 ffffffff 00effb00 DPL=3 CS64 [-RA] SS =002b 0000000000000000 ffffffff 00cff300 DPL=3 DS [-WA] DS =0000 0000000000000000 00000000 00000000 FS =0000 0000000000000000 00000000 00000000 GS =0000 0000000000000000 00000000 00000000 LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy GDT= 000000400091a000 0000007f IDT= 0000004000919000 000001ff CR0=80010001 CR2=0000000000000000 CR3=0000000000000000 CR4=00000220 DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 DR6=00000000ffff0ff0 DR7=0000000000000400 EFER=0000000000000500 qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x602e5482 thanks -- PMM
Le 18/03/2020 à 14:57, Peter Maydell a écrit : > On Tue, 17 Mar 2020 at 16:05, Laurent Vivier <laurent@vivier.eu> wrote: >> >> The following changes since commit 373c7068dd610e97f0b551b5a6d0a27cd6da4506: >> >> qemu.nsi: Install Sphinx documentation (2020-03-09 16:45:00 +0000) >> >> are available in the Git repository at: >> >> git://github.com/vivier/qemu.git tags/linux-user-for-5.0-pull-request >> >> for you to fetch changes up to 85db278520fd800d8e8de9a527c8f0e1a962055e: >> >> linux-user, openrisc: sync syscall numbers with kernel v5.5 (2020-03-17 16:36:17 +0100) >> >> ---------------------------------------------------------------- >> update syscall numbers to linux 5.5 (with scripts) >> add futex_time64/clock_gettime64/clock_settime64 >> add AT_EXECFN >> Emulate x86_64 vsyscalls >> >> v2: guard copy_to_user_timezone() with TARGET_NR_gettimeofday >> remove "Support futex_time64" patch >> guard sys_futex with TARGET_NR_exit >> >> ---------------------------------------------------------------- > > 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 > RAX=000000000000003f RBX=000000006ffffe34 RCX=00000040008004c0 > RDX=0000004000813180 > RSI=0000000000000064 RDI=00000040007ffff0 RBP=000000006fffff40 > RSP=00000040007fffe8 > R8 =0000000000000000 R9 =00000040008004fe R10=0000004000801a18 > R11=0000004000801260 > R12=0000004000800240 R13=0000000000000008 R14=0000000000400040 > R15=00000040008032d0 > RIP=00000040008117e9 RFL=00000246 [---Z-P-] CPL=3 II=0 A20=1 SMM=0 HLT=0 > ES =0000 0000000000000000 00000000 00000000 > CS =0033 0000000000000000 ffffffff 00effb00 DPL=3 CS64 [-RA] > SS =002b 0000000000000000 ffffffff 00cff300 DPL=3 DS [-WA] > DS =0000 0000000000000000 00000000 00000000 > FS =0000 0000000000000000 00000000 00000000 > GS =0000 0000000000000000 00000000 00000000 > LDT=0000 0000000000000000 0000ffff 00008200 DPL=0 LDT > TR =0000 0000000000000000 0000ffff 00008b00 DPL=0 TSS64-busy > GDT= 000000400091a000 0000007f > IDT= 0000004000919000 000001ff > CR0=80010001 CR2=0000000000000000 CR3=0000000000000000 CR4=00000220 > DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 > DR3=0000000000000000 > DR6=00000000ffff0ff0 DR7=0000000000000400 > EFER=0000000000000500 > qemu:handle_cpu_signal received signal outside vCPU context @ pc=0x602e5482 > Is this x86 on x86? I would say the problem is with the vsyscall patches. Thanks, Laurent
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. r~
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
On 3/18/20 12:58 PM, Laurent Vivier wrote: >> 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 ... > Perhaps it removes a dependency that should trigger the rebuild of > cpu_loop.o? Ah, yes indeed. It removes *all* dependencies for cpu_loop.o, so unless we touch the cpu_loop.c source file, nothing gets done. I think you're trying to be too fine grained here, since the *.o file has to go away with the *.d file. Why not just make ${arch}-linux-user/clean ? r~
Le 18/03/2020 à 21:17, Richard Henderson a écrit : > On 3/18/20 12:58 PM, Laurent Vivier wrote: >>> 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 > ... >> Perhaps it removes a dependency that should trigger the rebuild of >> cpu_loop.o? > > Ah, yes indeed. It removes *all* dependencies for cpu_loop.o, so unless we > touch the cpu_loop.c source file, nothing gets done. > > I think you're trying to be too fine grained here, since the *.o file has to go > away with the *.d file. Why not just > > make ${arch}-linux-user/clean > > ? The idea was to be able to bisect the series as the syscall_nr.h were added incrementally without rebuilding all the files. If I remove the loop in the configure where to add the "make ${arch}-linux-user/clean"? Thanks, Laurent
On 3/18/20 1:23 PM, Laurent Vivier wrote: > Le 18/03/2020 à 21:17, Richard Henderson a écrit : >> On 3/18/20 12:58 PM, Laurent Vivier wrote: >>>> 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 >> ... >>> Perhaps it removes a dependency that should trigger the rebuild of >>> cpu_loop.o? >> >> Ah, yes indeed. It removes *all* dependencies for cpu_loop.o, so unless we >> touch the cpu_loop.c source file, nothing gets done. >> >> I think you're trying to be too fine grained here, since the *.o file has to go >> away with the *.d file. Why not just >> >> make ${arch}-linux-user/clean >> >> ? > > The idea was to be able to bisect the series as the syscall_nr.h were > added incrementally without rebuilding all the files. > > If I remove the loop in the configure where to add the "make > ${arch}-linux-user/clean"? I don't know. Can you get an exit status out of the find? Another option might be for f in $(find ${arch}-linux-user -name '*.d' \ -exec grep -q ${arch_syscall} \ -print); do rm -f $(basename $f .d).* done But frankly I don't care if all of every file gets rebuilt while bisecting, it just needs to work. r~
Le 18/03/2020 à 21:42, Richard Henderson a écrit : > On 3/18/20 1:23 PM, Laurent Vivier wrote: >> Le 18/03/2020 à 21:17, Richard Henderson a écrit : >>> On 3/18/20 12:58 PM, Laurent Vivier wrote: >>>>> 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 >>> ... >>>> Perhaps it removes a dependency that should trigger the rebuild of >>>> cpu_loop.o? >>> >>> Ah, yes indeed. It removes *all* dependencies for cpu_loop.o, so unless we >>> touch the cpu_loop.c source file, nothing gets done. >>> >>> I think you're trying to be too fine grained here, since the *.o file has to go >>> away with the *.d file. Why not just >>> >>> make ${arch}-linux-user/clean >>> >>> ? >> >> The idea was to be able to bisect the series as the syscall_nr.h were >> added incrementally without rebuilding all the files. >> >> If I remove the loop in the configure where to add the "make >> ${arch}-linux-user/clean"? > > I don't know. Can you get an exit status out of the find? > > Another option might be > > for f in $(find ${arch}-linux-user -name '*.d' \ > -exec grep -q ${arch_syscall} \ > -print); do > rm -f $(basename $f .d).* > done > > But frankly I don't care if all of every file gets rebuilt while bisecting, it > just needs to work. ok, thank you for your help. I'm going to resend the pull request without this series to have more time to find a solution and to test it. Thanks, Laurent
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. > I removed this series from the final pull request as the problem doesn't seem related to change I made in configure. I didn't find from where the problem comes. Could you check if you are always able to reproduce the problem with master? Thanks, Laurent
On 3/23/20 1:33 PM, Laurent Vivier wrote: > 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. >> > > I removed this series from the final pull request as the problem doesn't > seem related to change I made in configure. > > I didn't find from where the problem comes. > > Could you check if you are always able to reproduce the problem with master? I could not replicate it today with master at 787f82407c5. r~