login
Search
Andrew Morton <akpm@linux-foundation.org> wrote on 10.06.2008 07:01:49:;) Thanks for the report. These look like the "known architecture problems" that I've hinted at in the gcov announcement post (I'm assuming this is x86_64 as I've seem similar reports in the past). Possible reasons: 1) initrd overwrites kernel: When kernel and initrd are loaded to static addresses, the oversized gcov kernel may overlap with the initrd load address. Solution: move initrd loading address. 2) out-of-memory: Kernel plus profiling code may just not fit into a minimal memory configuration any more. Solution: add memory. 3) write-protection of kernel code: gcc keeps profiling code and data close together in the .text section. Solution: any mechanism that protects .text against writes should be disabled when running a profiled kernel. 4) as of yet undiscovered incompatibilities between arch-dependent code and gcc's -fprofile-arcs option. Examples would be: * code which is run before memory access preparations were made * hard coded section sizes * relative address displacements which are out of range Unfortunately I neither have access to a machine nor the skill to debug 4) myself, so if 1)-3) can be ruled out, I'd like to ask for more help on this one: First off, someone needs to track down the offending file(s). This is done by putting a line containing "GCOV := n" in all Makefiles below arch/x86_64 (or go one step further back and set CONFIG_GCOV_PROFILE_ALL=n). If my assumption is correct, then the kernel should boot fine afterwards. In that case, remove the lines again one-by-one, while compiling and booting after each change. If the problem can be narrowed down to a single Makefile, replace the single "GCOV := n" line with multiple "GCOV_file.o := n" lines, one for each generated object file. Then again, same approach as before: remove those lines, compile and boot until it breaks. Finally post your results. At this point we would need someone with x86_64 arch skills to look at the file and find out why this code is broken with "-fprofile-arcs" enabled (on s390 we discovered at least one actual code bug this way, so the analysis might just be of general use). Alternatively we can just keep these files from being profiled. Regards, Peter --