trace-clock-rename-generic-identifier

Trace clock: rename generic identifier

> I am having the following trouble compiling kernel linux-2.6.30-rc5 when
> patched with patch-2.6.30-rc5-lttng-0.136 and wondered if this is a known
> problem...
> 
> ...
>   LD      kernel/time/built-in.o
>   CC      kernel/trace/ring_buffer.o
>   CC      kernel/trace/trace.o
>   CC      kernel/trace/trace_clock.o
>   CC      kernel/trace/trace_output.o
>   CC      kernel/trace/trace_stat.o
>   CC      kernel/trace/trace_printk.o
>   CC      kernel/trace/trace_nop.o
>   CC      kernel/trace/trace-clock-32-to-64.o
>   CC      kernel/trace/trace-clock.o
>   LD      kernel/trace/built-in.o
> kernel/trace/trace-clock.o:(.bss+0x0): multiple definition of `trace_clock'
> kernel/trace/trace_clock.o:trace_clock.c:(.text+0x0): first defined here
> arm-linux-ld: Warning: size of symbol `trace_clock' changed from 8 in
> kernel/trace/trace_clock.o to 4 in kernel/trace/trace-clock.o
> arm-linux-ld: Warning: type of symbol `trace_clock' changed from 2 to 1 in
> kernel/trace/trace-clock.o
> make[2]: *** [kernel/trace/built-in.o] Error 1
> make[1]: *** [kernel/trace] Error 2
> make: *** [kernel] Error 2
> 
> I *think* that this is because the symbol trace_clock appears as both a
> variable and a function.
> 
> FILE: include/asm-generic/trace-clock.h:
> 
> extern atomic_long_t trace_clock;
> 
> and
> 
> FILE: kernel/trace/trace_clock.c:
> 
> u64 notrace trace_clock(void)
> {
>       return cpu_clock(raw_smp_processor_id());
> }
> 

Hrm, yes. This is caused by ftrace. But given they are in mainline and 
LTTng isn't, the LTTng trace clock identifier will have to move.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>

0 files changed, 0 insertions, 0 deletions