Recently I've started seeing massive pch test suite failures with gcc, both trunk and 4.4, on armv5tel-linux-gnueabi: FAIL: gcc.dg/pch/common-1.c -O2 -I. (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O2 assembly comparison FAIL: gcc.dg/pch/common-1.c -O3 -fomit-frame-pointer -I. (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O3 -fomit-frame-pointer assembly comparison FAIL: gcc.dg/pch/counter-1.c -O0 -g -I. (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/counter-1.c -O3 -g -I. (test for excess errors) FAIL: gcc.dg/pch/counter-1.c -O3 -g assembly comparison FAIL: gcc.dg/pch/cpp-1.c -O0 -g -I. (test for excess errors) FAIL: gcc.dg/pch/cpp-1.c -O0 -g assembly comparison ...(many many more) These failures started after I did a major update of the Linux distro I run on my ARM boxes. I reverted a few likely suspects (glibc and the system gcc) to their earlier known-good versions, without effect, but in the end the failures were traced to the Linux kernel: - running linux-2.6.36-rc6 causes these PCH failures - reverting to linux-2.6.35 (similar .config) makes PCH tests pass again - pre-2.6.35 kernels are also known good The PCH test suite failures come from ICEs in cc1. I saved a core dump of which gdb says the following: Core was generated by `/home/mikpe/objdir/gcc/cc1 -quiet -I. -I. -iprefix /home/mikpe/temp/lib/gcc/arm'. Program terminated with signal 11, Segmentation fault. #0 linemap_lookup (set=0x40215000, line=73) at /home/mikpe/gcc-4.4-20100921/libcpp/line-map.c:284 284 if (line >= cached->start_location) Missing separate debuginfos, use: debuginfo-install glibc-2.10.2-1.bl8.armv5tel gmp-4.3.2-1.bl11.armv5tel mpfr-2.4.2-2.bl11.armv5tel (gdb) bt #0 linemap_lookup (set=0x40215000, line=73) at /home/mikpe/gcc-4.4-20100921/libcpp/line-map.c:284 #1 0x000cbed0 in diagnostic_report_current_module (context=0x790888) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:236 #2 0x000cbffc in diagnostic_report_current_function (context=0xa4680042, diagnostic=0x49) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:218 #3 0x000cc240 in default_diagnostic_starter (context=0xa4680042, diagnostic=0x49) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:263 #4 0x000cb6c4 in diagnostic_report_diagnostic (context=0x790888, diagnostic=0xbe88b8e0) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:403 #5 0x000cb940 in internal_error (gmsgid=0x6ecd70 "%s") at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:658 #6 0x00261cec in crash_signal (signo=-1098336032) at /home/mikpe/gcc-4.4-20100921/gcc/toplev.c:601 #7 <signal handler called> #8 linemap_lookup (set=0x40215000, line=73) at /home/mikpe/gcc-4.4-20100921/libcpp/line-map.c:284 #9 0x000cbed0 in diagnostic_report_current_module (context=0x790888) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:236 #10 0x000cbffc in diagnostic_report_current_function (context=0xa4680042, diagnostic=0x49) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:218 #11 0x000cc240 in default_diagnostic_starter (context=0xa4680042, diagnostic=0x49) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:263 #12 0x000cb6c4 in diagnostic_report_diagnostic (context=0x790888, diagnostic=0xbe88bcf8) at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:403 #13 0x000cbab0 in fatal_error (gmsgid=0x5ca9f0 "had to relocate PCH") at /home/mikpe/gcc-4.4-20100921/gcc/diagnostic.c:640 #14 0x0015da80 in gt_pch_restore (f=0xbe88bcf8) at /home/mikpe/gcc-4.4-20100921/gcc/ggc-common.c:576 #15 0x00054608 in c_common_read_pch (pfile=0x134f170, name=0x1347a68 "./valid-6.h.gch", fd=<value optimized out>, orig_name=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/gcc/c-pch.c:420 #16 0x00574a8c in should_stack_file (import=<value optimized out>, file=<value optimized out>, pfile=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/libcpp/files.c:710 #17 _cpp_stack_file (import=<value optimized out>, file=<value optimized out>, pfile=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/libcpp/files.c:795 #18 0x0056c168 in do_include_common (pfile=0x134f170, type=IT_INCLUDE) at /home/mikpe/gcc-4.4-20100921/libcpp/directives.c:784 #19 0x0056d028 in _cpp_handle_directive (pfile=0x134f170, indented=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/libcpp/directives.c:488 #20 0x00579d60 in _cpp_lex_token (pfile=0x134f170) at /home/mikpe/gcc-4.4-20100921/libcpp/lex.c:1265 #21 0x0057d3bc in cpp_get_token (pfile=0x134f170) at /home/mikpe/gcc-4.4-20100921/libcpp/macro.c:1235 #22 0x0057d620 in cpp_get_token_with_location (pfile=0x5ca9f0, loc=0xa1000) at /home/mikpe/gcc-4.4-20100921/libcpp/macro.c:1347 #23 0x0000c750 in c_lex_with_flags (value=0xbe88bf20, loc=0xbe88bf24, cpp_flags=0x0, lex_flags=0) at /home/mikpe/gcc-4.4-20100921/gcc/c-lex.c:306 #24 0x00055114 in c_lex_one_token (parser=0xbe88bf1c, token=0xbe88bf1c) at /home/mikpe/gcc-4.4-20100921/gcc/c-parser.c:201 #25 0x000628c0 in c_parser_peek_token (parser=<value optimized out>, parser=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/gcc/c-parser.c:310 #26 c_parse_file (parser=<value optimized out>, parser=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/gcc/c-parser.c:8324 #27 0x00049e3c in c_common_parse_file (set_yydebug=<value optimized out>) at /home/mikpe/gcc-4.4-20100921/gcc/c-opts.c:1252 #28 0x00263e24 in compile_file () at /home/mikpe/gcc-4.4-20100921/gcc/toplev.c:970 #29 do_compile () at /home/mikpe/gcc-4.4-20100921/gcc/toplev.c:2197 ---Type <return> to continue, or q <return> to quit--- #30 toplev_main () at /home/mikpe/gcc-4.4-20100921/gcc/toplev.c:2229 #31 0x4018c3e0 in __libc_start_main () from /lib/libc.so.6 #32 0x0000aef0 in _start () Note #13. Apparently gcc "had to relocate PCH" (whatever that means) and tries to issue a diagnostic, which fails miserably in linemap_lookup. I also noticed many kernel messages about alignment traps in cc1, with PC values in linemap_lookup(). I'll try to bisect the 2.6.36-rc kernel changes to see what caused the PCH breakage. But even if this turns out to be a kernel bug (as opposed to the kernel just doing something different but valid), I don't think it's Ok for gcc to SEGV if it "had to relocate PCH".
Most likely when the linux arm kernel decided to randomize the heap.
I assume other Linux archs already randomize the heap. If so, why would that cause PCH failures on ARM? Could it be because there's no TRY_EMPTY_VM_SPACE definition in gcc/config/host-linux.c for ARM?
(In reply to comment #2) > I assume other Linux archs already randomize the heap. Could it be because there's no TRY_EMPTY_VM_SPACE definition in gcc/config/host-linux.c for ARM? yes, a definition for TRY_EMPTY_VM_SPACE is needed for ARM. I just went through this for MIPS but I have not pushed it because I don't currently have a correct copyright assignment on file.
Ok. I'll cook something up for TRY_EMPTY_VM_SPACE on ARM.
(In reply to comment #1) > Most likely when the linux arm kernel decided to randomize the heap. Confirmed. Bisection of the kernel identified: From: Nicolas Pitre <nico@fluxnic.net> Date: Tue, 15 Jun 2010 01:16:19 +0000 (-0400) Subject: [ARM] add address randomization to mmap() X-Git-Tag: v2.6.36-rc1~591^2^2~6^2~2 X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=cc92c28b2db5b406657ecc05235d4ca4e222ae34 [ARM] add address randomization to mmap() Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org> --- diff --git a/arch/arm/mm/mmap.c b/arch/arm/mm/mmap.c index f5abc51..4f5b396 100644 --- a/arch/arm/mm/mmap.c +++ b/arch/arm/mm/mmap.c @@ -7,6 +7,7 @@ #include <linux/shm.h> #include <linux/sched.h> #include <linux/io.h> +#include <linux/random.h> #include <asm/cputype.h> #include <asm/system.h> @@ -80,6 +81,9 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr, start_addr = addr = TASK_UNMAPPED_BASE; mm->cached_hole_size = 0; } + /* 8 bits of randomness in 20 address space bits */ + if (current->flags & PF_RANDOMIZE) + addr += (get_random_int() % (1 << 8)) << PAGE_SHIFT; full_search: if (do_align) as the cause of this regression. Still, I think the kernel is Ok and it's really gcc's pch implementation which is broken.
Created attachment 22030 [details] define TRY_EMPTY_VM_SPACE for ARM Preliminary patch which defines TRY_EMPTY_VM_SPACE for ARM and fixes the PCH regressions in a PCH-only test run. I'll submit it after some more testing.
The patch tested ok and has now been submitted: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02252.html
Please can you confirm that this is now fixed in trunk, Mikael. And has it been backported?
(In reply to comment #8) > Please can you confirm that this is now fixed in trunk, Mikael. No, it has not been fixed on trunk. > And has it been backported? Not in the official gcc repository. I do use the fix in my private 4.4 and 4.5 based compilers.
Author: ramana Date: Thu May 5 09:52:12 2011 New Revision: 173421 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173421 Log: For Michael Hope. 2011-05-05 Michael Hope <michael.hope@linaro.org> PR pch/45979 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for __ARM_EABI__ hosts. Modified: trunk/gcc/ChangeLog trunk/gcc/config/host-linux.c
Fixed.
Author: michaelh Date: Fri Mar 23 02:19:46 2012 New Revision: 185724 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185724 Log: 2012-03-16 Michael Hope <michael.hope@linaro.org> Backport from mainline 2011-05-05 Michael Hope <michael.hope@linaro.org> PR pch/45979 * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for __ARM_EABI__ hosts. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/host-linux.c