This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
19.05.2016 16:07, The Source ÐÐÑÐÑ:
19.05.2016 11:49, The Source ÐÐÑÐÑ: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.19.05.2016 10:37, The Source ÐÐÑÐÑ: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.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 toavoid using __cpuid()? My glibc version is 2.22You 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?
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 cpuidSo cpuid pops up here and there even if everything is built for i486. Isn't there a way to completely get rid of it?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |