Re: problem with __init_cpu_features()

Re: problem with __init_cpu_features()

[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
>>> <carlos@systemhalted.org> wrote:
>>>> On Wed, May 18, 2016 at 10:37 AM, The Source 
>>>> <thesourcehim@gmail.com> 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.



--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: problem with __init_cpu_features()

[The Source]

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
>>>> <carlos@systemhalted.org> wrote:
>>>>> On Wed, May 18, 2016 at 10:37 AM, The Source 
>>>>> <thesourcehim@gmail.com> 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

Re: problem with __init_cpu_features()

[Carlos O'Donell]

On Thu, May 19, 2016 at 10:40 AM, The Source <thesourcehim@gmail.com> wrote:
> 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 */

There should be no use of cpuid inside libpthread.

What is failing here?

> 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

That would be a gcc bug. File a bug in their tracker.

> 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?

Nobody builds for i486 anymore, so what you're seeing is just bitrot
from an untested configuration.

Please file bugs and we'll fix everything you can find.

Cheers,
Carlos.

--
For unsubscribe information see http://sourceware.org/lists.html#faq