From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54983 invoked by alias); 19 May 2016 14:41:05 -0000 Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org Received: (qmail 54958 invoked by uid 89); 19 May 2016 14:41:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=0.9 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,FREEMAIL_FROM,GARBLED_BODY,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 spammy=19052016, 19.05.2016, =d0=b5=d1, =d0=bf=d0=b8=d1?= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lf0-f44.google.com Received: from mail-lf0-f44.google.com (HELO mail-lf0-f44.google.com) (209.85.215.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 19 May 2016 14:40:54 +0000 Received: by mail-lf0-f44.google.com with SMTP id m64so38068945lfd.1; Thu, 19 May 2016 07:40:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kNLYf9p9l7MIeEVFhroaPV7PT8SENnCtYt7XtkRYGD8=; b=dDWOAqQ0Vj9RSk19Svo5e/Yw4sruJkN5wAmy1uPevJrZRs3q3yUj/krrn8Zha4Nw5s XYxjtbKbYN0Rno76owxvC+MJPvuW7Fbl08Gw2Xr7J60ThyMpmg6yfjzrEfkErjke24DE SngWoK/4zpYQM1hJJE9aolMrq+0p3o3dIWuGuD/0tus39x+YybWSUzQ5AfzhyBKPHzzQ 39rmJZKhbudDe6tEri1JaPc2fqxSdwQhmF1WDbiT0Nzc2kHXpge56xzF461U0DkDchrq VI4yxKx/QC5XNSV6XC2ryC6rQ5Q6yDQUBavK6hE8tntlZIP6aPnFFHi7U3ddlWjCT/XB MA8A== X-Gm-Message-State: AOPr4FWZhYXhp+MJLJO4ZIYg+k24LPaHWnyQeGWrwaeESn9zZotzrr6gv0NYKQq/tWfNyA== X-Received: by 10.25.210.144 with SMTP id j138mr4247853lfg.77.1463668851206; Thu, 19 May 2016 07:40:51 -0700 (PDT) Received: from [10.50.2.215] ([83.137.219.187]) by smtp.googlemail.com with ESMTPSA id k9sm2474261lfb.4.2016.05.19.07.40.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2016 07:40:50 -0700 (PDT) Subject: Re: problem with __init_cpu_features() To: libc-help@sourceware.org, crossgcc@sourceware.org References: <64f1a37c-8aa5-be67-eec1-88893ec0d1cf@gmail.com> <03f98607-1993-5dc3-5774-99fe01544886@gmail.com> <8d1c4d18-0915-ac7a-25cb-f531a323b39c@gmail.com> <71a932f2-5e59-ed1e-910c-18b9c1e9089b@gmail.com> From: The Source Message-ID: Date: Thu, 19 May 2016 14:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <71a932f2-5e59-ed1e-910c-18b9c1e9089b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2016-05/txt/msg00015.txt.bz2 19.05.2016 16:07, The Source пишет: > 19.05.2016 11:49, The Source пишет: >> 19.05.2016 10:37, The Source пишет: >>> 18.05.2016 21:53, Carlos O'Donell пишет: >>>> On Wed, May 18, 2016 at 10:55 AM, Carlos O'Donell >>>> wrote: >>>>> On Wed, May 18, 2016 at 10:37 AM, The Source >>>>> wrote: >>>>>> Hello, I'm trying to run my application on Cyrix Cx486SLC based >>>>>> system. But >>>>>> application (built for i486 as well as glibc) crashes on illegal >>>>>> instruction >>>>>> inside __init_cpu_features(). As far as I understand this CPU >>>>>> does not >>>>>> support cpuid (/proc/cpuinfo reports cpuid level -1 and >>>>>> /dev/cpu/0/cpuid can >>>>>> not be read with i/o error), so that might be the problem. Is >>>>>> there a way to >>>>>> avoid using __cpuid()? My glibc version is 2.22 >>>>> You must use specific CFLAGS or CC to indicate you are building for a >>>>> pre-i586 target, that will disable unconditional cpuid usage, and >>>>> enable the checks required to verify cpuid is usable. >>>>> >>>>> If you are cross-compiling from an x86_64 box I would recommend >>>>> CC="gcc -m32 -march=i486" instead to ensure that regardless of flags >>>>> you build for i486. >>>>> >>>>> Just to check I kicked off a build for i486 locally to see if runs >>>>> into any problems. >>>> i486 builds just fine and I verified it calls __get_cpuid_max to check >>>> for cpuid feature. >>>> >>>> Test results look good too. >>>> >>>> Cheers, >>>> Carlos. >>> >>> Unfortunately, adding those flags to compiler for both libc and >>> application did not help. I found out that __init_cpu_features is >>> located inside libpthread somehow. So my application crashes when it >>> uses threads. Could there be some unwanted optimization inside pthread? >>> >> Hmm, I see some strange things in glibc config.log. It appears that >> some subconfigs are called with i686 despite main script is called >> with --with-cpu=i486. Trying to figure out if it's configure bug or >> crosstools-ng. >> >> > I'm out of ideas. I tried to restrict gcc from building anything but > i486 (by passing the following flags to configure of both gcc and > glibc: --with-cpu=i486 --with-cpu-32=i486 --with-arch=i486 > --with-arch-32=i486 --enable-targets=i486), but it did not help, I > still see those i686 successful tests in config.log and libpthread > still has __init_cpu_features. If anyone have any idea how to forbid > i686, I'm open for suggestions, thank you. > > Some more findings: 1. I changed libc code slightly to avoid using cpuid inside pthread: sysdeps/unix/sysv/linux/x86/elision-conf.c Replaced all usage of HAS_RTM to 0: __elision_available = 0;//HAS_RTM; #ifdef ENABLE_LOCK_ELISION __pthread_force_elision = __libc_enable_secure ? 0 : __elision_available; #endif //if (!HAS_RTM) __elision_aconf.retry_try_xbegin = 0; /* Disable elision on rwlocks */ 2. And crash has gone from libpthread. But poped up in different place: libgcc_s: libgcc/config/i386/cpuinfo.c __cpu_indicator_init function uses cpuid So cpuid pops up here and there even if everything is built for i486. Isn't there a way to completely get rid of it? -- For unsubscribe information see http://sourceware.org/lists.html#faq