linux-kernel - Re: VIA C7 / VIA PC-1 (PC2500) anyone?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Jun 2007 16:19:36 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: VIA C7 / VIA PC-1 (PC2500) anyone?

Linux-kernel wrote:
[]
> To me it looks like a wrong choice of gcc switches to user-mode programs. What
> distribution are you using? try compiling failing programs from source with
> conservative command line switches to gcc. See if things change.

Wrong choice of gcc switches tends to produce binaries wich are either works
or does not.  Here, it sometimes works and sometimes does not.  Also, if
it was wrong options, programs usually tends to fail with something like
SIGILL (Illegal Instruction), not SIGSEGV.

The system is running Debian Etch (4.0), with everything compiled for plain
i386 (default gcc -O2 without any fancy optimizations).

I tried installing libc6-i686 package (cmov-enabled glibc) - unlike with
VIA C3 (which indeed does not have this instruction), it worked on C7, but
installing libc6-i686 didn't change SIGSEGVs at all.

I just tried to recompile man(1) command (the one that gave SIGSEGVs most
often).  The resulting binary fails MUCH less often, but still sometimes
fails.

Note that this is real i686 CPU.  At least according to kernel - when one
chooses C7 CPU in kernel config, kernel uses -march=i686 switch - the only
CPU-specific switch it is.  The difference between i686 and C7 in kernel
config is cache shift value.

Thanks.

/mjt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/