Re: Bug#983583: FTBFS on mips64el and mipsel
YunQiang Su <wzssyqa@gmail.com> 于2021年3月29日周一 下午4:56写道：
>
> YunQiang Su <wzssyqa@gmail.com> 于2021年3月29日周一 下午1:31写道：
> >
> > YunQiang Su <wzssyqa@gmail.com> 于2021年3月29日周一 下午1:06写道：
> > >
> > > YunQiang Su <wzssyqa@gmail.com> 于2021年3月29日周一 上午11:45写道：
> > > >
> > > > Shengjing Zhu <zhsj@debian.org> 于2021年3月29日周一 上午11:40写道：
> > > > >
> > > > > On Mon, Mar 29, 2021 at 09:22:29AM +0800, YunQiang Su wrote:
> > > > > > Shengjing Zhu <zhsj@debian.org> 于2021年3月28日周日 上午12:12写道：
> > > > > > >
> > > > > > > Control: reopen -1
> > > > > > > Control: severity -1 important
> > > > > > >
> > > > > > > On Sat, Mar 27, 2021 at 11:46 PM Adrian Bunk <bunk@debian.org> wrote:
> > > > > > > >
> > > > > > > > On Sat, Feb 27, 2021 at 02:33:38AM +0800, Shengjing Zhu wrote:
> > > > > > > > > Source: golang-github-sylabs-sif
> > > > > > > > > Version: 1.0.9-2
> > > > > > > > > Severity: serious
> > > > > > > > > X-Debbugs-Cc: zhsj@debian.org
> > > > > > > > >
> > > > > > > > > Tried 3 times on buildd and failed at same test.
> > > > > > > > >
> > > > > > > > > === RUN TestAddDelObject
> > > > > > > > > unexpected fault address 0xffc8a0c000
> > > > > > > > > fatal error: fault
> > > > > > > > > [signal SIGSEGV: segmentation violation code=0x2 addr=0xffc8a0c000 pc=0x12007ebe4]
> > > > > > > > >
> > > > > > > > > goroutine 22 [running]:
> > > > > > > > > runtime.throw(0x1201b74ed, 0x5)
> > > > > > > > > /usr/lib/go-1.15/src/runtime/panic.go:1116 +0x6c fp=0xc0000e3430 sp=0xc0000e3408 pc=0x120040afc
> > > > > > > > > runtime.sigpanic()
> > > > > > > > >
> > > > > > > > > Since it has been built on mipsx before, the failure will cause it impossible
> > > > > > > > > to fix issue later on these arch.
> > > > > > > > >
> > > > > > > > > It should either be removed from these arch or get fixed.
> > > > > > > >
> > > > > > > > This appears to be fixed now:
> > > > > > > > https://buildd.debian.org/status/package.php?p=golang-github-sylabs-sif
> > > > > > >
> > > > > > > The difference between these builds, seems to be a 5.10 kernel and
> > > > > > > 4.19 kernel on buildd.
> > > > > > >
> > > > > > > I'll reopen this but downgrade the severity, and loop debian-mips@ to
> > > > > > > see if it's regression on the kernel side.
> > > > > > >
> > > > > >
> > > > > > And the CPUs are different: Cavium for good and Loongson3A3000 is bad.
> > > > > >
> > > > >
> > > > > On https://buildd.debian.org/status/logs.php?pkg=golang-github-sylabs-sif&ver=1.0.9-2%2Bb2&arch=mips64el
> > > > >
> > > > > The failed buildd are: mipsel-manda-04, succeeded one are mipsel-aql-01.
> > > > > From the build log,
> > > > >
> > > > > mipsel-manda-04: Kernel: Linux 5.10.0-0.bpo.3-loongson-3
> > > > > mipsel-aql-01: Kernel: Linux 4.19.0-16-loongson-3
> > > > >
> > > >
> > > > Ohh, my mistake: mips-aql-01 vs mipsel-aql-01 ;)
> > > >
> > >
> > > WIth some test.
> > >
> > > This problem is also about O32_FP64 support option.
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962485
> > >
> > > It is quite strange this option may effect mips64el.
> > > Anyway, lets revert it.
> > >
> > > I will continue to dig the real problem.
> > >
> >
> > Ennnn, the problem is about Loongson 3A 1000 vs Loongson 3A2000/3000.
> > I test it on
> >
> > 3B1500 + O32_FP64 -> workable
> > 3B1500 + nO32_FP64 -> workable
> > 3A2000 + O32_FP64 -> fail
> > 3A2000 + nO32_FP64 -> fail
> >
>
> Sorry, it is not about O32_FP64, it is about memory region.
> Loongson 3A2000+ supports RI/XI, which stop the access of some memory region.
>
> The problem is about Go itself: why it map the datafile writeonly.
>2
I figure out a patch, with which it can build now:
--- golang-github-sylabs-sif-1.0.9/pkg/sif/load.go 2019-12-19
19:58:23.000000000 +0000
+++ golang-github-sylabs-sif-1.0.9-patched/pkg/sif/load.go
2021-03-29 09:49:44.789742245 +0000
@@ -92,7 +92,8 @@
flags := syscall.MAP_PRIVATE
if !rdonly {
- prot = syscall.PROT_WRITE
+ prot = syscall.PROT_WRITE | syscall.PROT_READ
+ // prot = syscall.PROT_WRITE
flags = syscall.MAP_SHARED
}
mmap(2) says that
On some hardware architectures (e.g., i386), PROT_WRITE implies
PROT_READ. It is architecture dependent whether PROT_READ
implies PROT_EXEC or not. Portable programs should always set
PROT_EXEC if they intend to execute code in the new mapping.
So, I guess it is due to architecture differences.
> > >
> > > > > It doesn't seem to have Cavium CPU here.
> > > > >
> > > >
> > > >
> > > > --
> > > > YunQiang Su
> > >
> > >
> > >
> > > --
> > > YunQiang Su
> >
> >
> >
> > --
> > YunQiang Su
>
>
>
> --
> YunQiang Su
--
YunQiang Su
Reply to: