diff for duplicates of <541FEC77.3010905@gentoo.org> diff --git a/a/1.txt b/N1/1.txt index 3eb2ca6..472b25b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -51,61 +51,3 @@ On 09/08/2014 05:44, Joshua Kinard wrote: I did some more tracing. It seems the issue with glibc itself stems from the addition of __atomic_* builtins added generally in gcc-4.7 and MIPS-specifically in gcc-4.8: - -From ports/sysdeps/mips/bits/atomic.h (for 2.19) or sysdeps/mips/bits/atomic.h -(for 2.20): - -/* The __atomic_* builtins are available in GCC 4.7 and later, but MIPS - support for their efficient implementation was added only in GCC 4.8. - We still want to use them even with GCC 4.7 for MIPS16 code where we - have no assembly alternative available and want to avoid the __sync_* - builtins if at all possible. */ - -#if __GNUC_PREREQ (4, 8) || (defined __mips16 && __GNUC_PREREQ (4, 7)) -[snip] - -This is why the assembly is different between the two gcc versions. This same -code is in the kernel's atomic.h copy under arch/mips/include/asm/ as well. - -I tested by removing the top part of the #if macro and basically forcing the -inline versions only, then rebuilt glibc-2.20 with gcc-4.9.2 (20140921 -prerelease), and lo and behold, sln executes and returns its usage information. - When using the gcc internal builtins, a futex gets used, which is why I wasn't -seeing futexes in 4.7-built copies of sln, only in 4.8 or greater-built copies. - This means that the gcc internal __atomic_* builtins may be somewhat to blame -for this problem on R1x000 systems. - -I traced the kernel side of the problem out and figured out that when the futex -is taken by sln, the process gets frozen by the scheduler via a call to -freezable_schedule() in function futex_wait_queue_me in kernel/futex.c. I -added two printk statements, one before freezable_schedule() and one after, and -the first statement executes (verified by dumping /proc/kmsg directly because -dmesg itself generates futexes), but not the printk after. The printk after -freezable_schedule() only executes when I ctrl+C the frozen process and it -exits out of the futex code. - -I visually checked through include/linux/freezer.h and noticed that -freezable_schedule eventually calls freezing(), which executes an atomic_read() -on system_freezing_cnt. In the mips code, that just comes out as a pointer -dereference of a volatile variable. I'm not certain, though, if in gcc's case, -the use of volatile means it tries to use its builtin __atomic_ functions -again, and tries to take another futex /while it's trying to take a futex/. -Chicken and egg? - -So, could still very well be a gcc issue, or maybe it's something really subtle -in the kernel code. I am not sure which. I at least know of a specific gcc -commit that enables/disables the problem, and that's pointing the finger at gcc -here. - -Ideas? - --- -Joshua Kinard -Gentoo/MIPS -kumba@gentoo.org -4096R/D25D95E3 2011-03-28 - -"The past tempts us, the present confuses us, the future frightens us. And our -lives slip away, moment by moment, lost in that vast, terrible in-between." - ---Emperor Turhan, Centauri Republic diff --git a/a/content_digest b/N1/content_digest index 5ed14bb..515addd 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -59,64 +59,6 @@ "\n" "I did some more tracing. It seems the issue with glibc itself stems from the\n" "addition of __atomic_* builtins added generally in gcc-4.7 and\n" - "MIPS-specifically in gcc-4.8:\n" - "\n" - "From ports/sysdeps/mips/bits/atomic.h (for 2.19) or sysdeps/mips/bits/atomic.h\n" - "(for 2.20):\n" - "\n" - "/* The __atomic_* builtins are available in GCC 4.7 and later, but MIPS\n" - " support for their efficient implementation was added only in GCC 4.8.\n" - " We still want to use them even with GCC 4.7 for MIPS16 code where we\n" - " have no assembly alternative available and want to avoid the __sync_*\n" - " builtins if at all possible. */\n" - "\n" - "#if __GNUC_PREREQ (4, 8) || (defined __mips16 && __GNUC_PREREQ (4, 7))\n" - "[snip]\n" - "\n" - "This is why the assembly is different between the two gcc versions. This same\n" - "code is in the kernel's atomic.h copy under arch/mips/include/asm/ as well.\n" - "\n" - "I tested by removing the top part of the #if macro and basically forcing the\n" - "inline versions only, then rebuilt glibc-2.20 with gcc-4.9.2 (20140921\n" - "prerelease), and lo and behold, sln executes and returns its usage information.\n" - " When using the gcc internal builtins, a futex gets used, which is why I wasn't\n" - "seeing futexes in 4.7-built copies of sln, only in 4.8 or greater-built copies.\n" - " This means that the gcc internal __atomic_* builtins may be somewhat to blame\n" - "for this problem on R1x000 systems.\n" - "\n" - "I traced the kernel side of the problem out and figured out that when the futex\n" - "is taken by sln, the process gets frozen by the scheduler via a call to\n" - "freezable_schedule() in function futex_wait_queue_me in kernel/futex.c. I\n" - "added two printk statements, one before freezable_schedule() and one after, and\n" - "the first statement executes (verified by dumping /proc/kmsg directly because\n" - "dmesg itself generates futexes), but not the printk after. The printk after\n" - "freezable_schedule() only executes when I ctrl+C the frozen process and it\n" - "exits out of the futex code.\n" - "\n" - "I visually checked through include/linux/freezer.h and noticed that\n" - "freezable_schedule eventually calls freezing(), which executes an atomic_read()\n" - "on system_freezing_cnt. In the mips code, that just comes out as a pointer\n" - "dereference of a volatile variable. I'm not certain, though, if in gcc's case,\n" - "the use of volatile means it tries to use its builtin __atomic_ functions\n" - "again, and tries to take another futex /while it's trying to take a futex/.\n" - "Chicken and egg?\n" - "\n" - "So, could still very well be a gcc issue, or maybe it's something really subtle\n" - "in the kernel code. I am not sure which. I at least know of a specific gcc\n" - "commit that enables/disables the problem, and that's pointing the finger at gcc\n" - "here.\n" - "\n" - "Ideas?\n" - "\n" - "-- \n" - "Joshua Kinard\n" - "Gentoo/MIPS\n" - "kumba@gentoo.org\n" - "4096R/D25D95E3 2011-03-28\n" - "\n" - "\"The past tempts us, the present confuses us, the future frightens us. And our\n" - "lives slip away, moment by moment, lost in that vast, terrible in-between.\"\n" - "\n" - --Emperor Turhan, Centauri Republic + MIPS-specifically in gcc-4.8: -d096c176824453f25e6bf8488bbe5d4c8a8b518f25d3cb6b865bd10ede2092b6 +d97303350512771fdd4cbe55ac6d2730a5ee54df415f6c175e4fb90b6ac90ee1
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.