Bug#871514: clamav: FTBFS on mips64el
Control: forcemerge -1 872438
Hi,
Just a brief update on this bug. Unfortunately there is still no "good" fix.
As I have written in a few places now, the bug occurs on mips64el where
a "small" variable gets spilled to the stack. It is possible that GCC
writes the variable to the stack using a small instruction (like sw for
a 32-bit store) and then reloads it as a 64-bit integer (using ld). This
means that the upper bits of the loaded value will contain garbage
causing chaos later when the value is used.
The bug is almost certainly in the LRA part of the compiler which
handles spilling values to the stack. One possible temporary workaround
(originally suggested by Adrian Bunk) would be to disable LRA on
mips64el. I have tested the attached patch which does seem to work. The
disadvantage of this is that non-LRA hasn't really been tested on MIPS
for ages so it might introduce some other bugs. Given the scale of this
issue it might be worth it?
This bug is very closely related to an earlier GCC bootstrap failure on
mips64el: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78660
In comment 17 Matthew sent a patch and applying it also fixes this bug.
However, he tells me it has some other issues and isn't suitable to be
applied (which is presumably why it was reverted).
James
commit 21398b7c319ed013741a9b249cb2315a098b6753
Author: James Cowgill
Date: Tue Aug 22 11:33:47 2017 +0100
Disable LRA on mips as a workaround
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 563f74b74f0..c89067cf89c 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -19738,7 +19738,7 @@ mips_option_override (void)
else if (ISA_MIPS1 && !TARGET_FLOAT32)
error ("%<-march=%s%> requires %<-mfp32%>", mips_arch_info->name);
else if (TARGET_FLOATXX && !mips_lra_flag)
-error ("%<-mfpxx%> requires %<-mlra%>");
+mips_lra_flag = 1;
/* End of code shared with GAS. */
diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index ced243218e3..cf7795c63e4 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -385,7 +385,7 @@ Target Report Mask(SYNCI)
Use synci instruction to invalidate i-cache.
mlra
-Target Report Var(mips_lra_flag) Init(1) Save
+Target Report Var(mips_lra_flag) Init(0) Save
Use LRA instead of reload.
mlxc1-sxc1
signature.asc
Description: OpenPGP digital signature
Bug#871514: clamav: FTBFS on mips64el
control: reassign -1 gcc-7 7.1.0-12 control: affects -1 clamav On 2017-08-09 16:43:29 [+0200], Aurelien Jarno wrote: > I got a quick look. It's indeed a regression introduced by GCC 7. It can > be workarounded by building the file with -O0, but already appears with > -O1 optimization. > > I got a quick look with gdb and it seems that loading either the rc > (enum) or infect (bool variable to test it against 0, the load is done > with the ld instruction instead of the lw instruction. It means garbage > from another local variable is loaded into the high 32 bits, which > causes the comparison against 0 to be false instead of true. Thanks for looking at this. I reassinged this bug to gcc-7. Would forwarding the bug gcc upstream with the mbox.i be any help? I could a label around the check so the comparison could be located in .S easier, just don't know if this helps. > Aurelien > Sebastian
Bug#871514: clamav: FTBFS on mips64el
On 2017-08-08 20:41, Sebastian Andrzej Siewior wrote: > On 2017-08-08 20:34:37 [+0200], To sub...@bugs.debian.org wrote: > … > > returned (the important part): > > |LibClamAV debug: parseEmailBody() rc 1 infect 0 > > |LibClamAV debug: parseEmailBody() returning 3 > … > > The exp build passed with gcc-6_6.4.0-1 [0]. Is there an easy way to > > downgrade the compiler on eller/porterbox? Or could a porter double > > check this please? > > on eller in a buster chroot: > |LibClamAV debug: parseEmailBody() rc 1 infect 0 > |LibClamAV debug: parseEmailBody() returning 1 > > further suggestions? I got a quick look. It's indeed a regression introduced by GCC 7. It can be workarounded by building the file with -O0, but already appears with -O1 optimization. I got a quick look with gdb and it seems that loading either the rc (enum) or infect (bool variable to test it against 0, the load is done with the ld instruction instead of the lw instruction. It means garbage from another local variable is loaded into the high 32 bits, which causes the comparison against 0 to be false instead of true. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#871514: clamav: FTBFS on mips64el
On 2017-08-08 20:34:37 [+0200], To sub...@bugs.debian.org wrote: … > returned (the important part): > |LibClamAV debug: parseEmailBody() rc 1 infect 0 > |LibClamAV debug: parseEmailBody() returning 3 … > The exp build passed with gcc-6_6.4.0-1 [0]. Is there an easy way to > downgrade the compiler on eller/porterbox? Or could a porter double > check this please? on eller in a buster chroot: |LibClamAV debug: parseEmailBody() rc 1 infect 0 |LibClamAV debug: parseEmailBody() returning 1 further suggestions? Sebastian
Bug#871514: clamav: FTBFS on mips64el
Package: clamav
Version: 0.99.2+dfsg-6
Severity: serious
The last build of clamav (0.99.3~beta1+dfsg-1) failed on mips64el.
However the build in experimtal (0.99.3~snapshot…) succeeded and code
change is very minimal (almost non-existing). The I tried 0.99.2+dfsg-6
on eller and it failed, too but passed in the past.
I looked slightly more closely on eller. After a complete build, the
command
|clamscan/clamscan --gen-json --quiet -dunit_tests/test-1/test-db \
| unit_tests/input/phish-test-clean unit_tests/input/phish-test-cloak \
| unit_tests/input/phish-test-ssl --log=clamscan2.log --debug
returned (the important part):
|LibClamAV debug: parseEmailBody() rc 1 infect 0
|LibClamAV debug: parseEmailBody() returning 3
the matching C code by the end of parseEmailBody():
| cli_dbgmsg("parseEmailBody() rc %d infect %d\n", (int)rc, infected);
| if ((rc != FAIL) && infected)
| rc = VIRUS;
|
| cli_dbgmsg("parseEmailBody() returning %d\n", (int)rc);
and rc is type mbox_status:
| typedef enum {
| FAIL,
| OK,
| OK_ATTACHMENTS_NOT_SAVED,
| VIRUS,
| MAXREC,
| MAXFILES
| } mbox_status;
So rc is != FAIL and infected is 0 but the compiler manages to set rc to
VIRUS / 3.
The exp build passed with gcc-6_6.4.0-1 [0]. Is there an easy way to
downgrade the compiler on eller/porterbox? Or could a porter double
check this please?
[0]
https://buildd.debian.org/status/fetch.php?pkg=clamav&arch=mips64el&ver=0.99.3~snapshot20170704%2Bdfsg-1&stamp=1499981584&raw=0
Sebastian
