Hi all,
After da48d094ce5d ("Kconfig: remove HAVE_LATENCYTOP_SUPPORT"),
CONFIG_LATENCYTOP can be selected on all architectures. Unfortunately,
viro reported that this breaks the build for ia64:
arch/ia64/kernel/entry.S: Assembler messages:
arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)
arch/ia64/kernel/entry.S:728: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)
arch/ia64/kernel/entry.S:859: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)
make[1]: *** [arch/ia64/kernel/entry.o] Error 1
This is because the task_struct is over 8K thanks to the latency_record
array, which means that the 14-bit immediate offset expected by the adds
instruction to grab hold of the thread info flags is now out-of-range on
ia64. I had a quick go at fixing it in entry.S, but I ended up with
worse code due to the need to perform the offset calculation as a
separate step (which introduces a hazard).
We could simply revert da48d094ce5d to make the problem disappear, but
I'd be interested to know whether or not this is an ia64-specific problem
and therefore whether LATENCYTOP should be opt-out as opposed to opt-in
for a given architecture.
Prior to da48d094ce5d, arc, arm, metag, microblaze, parisc, powerpc,
s390, sh, sparc, unicore32 and x86 all selected HAVE_LATENCYTOP_SUPPORT
so assumedly they don't run into problems. arm64 also works ok with the
option enabled.
Will
--->8
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ecb9e75614bf..9c66339e3879 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1600,6 +1600,7 @@ config LATENCYTOP
depends on DEBUG_KERNEL
depends on STACKTRACE_SUPPORT
depends on PROC_FS
+ depends on !IA64
select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC
select KALLSYMS
select KALLSYMS_ALL
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
