sys/x86/isa/clock.c:189: undefined reference to `cyclic_clock_func'

[J. Hellenthal]

On Tue, 8 Mar 2011 16:31, jhb@ wrote:
> On Tuesday, March 08, 2011 10:19:30 am J. Hellenthal wrote:
>>
>> On Tue, 8 Mar 2011 04:18, jhell@ wrote:
>>> On Tue, 8 Mar 2011 03:29, jhell@ wrote:
>>>>
>>>> Hello Stable@,
>>>>
>>>> Compiling a kernel on stable/8 with DTrace support is failing with the
>>>> above
>>>> subject line upon linking kernel.debug.
>>>>
>>>> The text leading up to this is:
>>>> ...
>>>> ctfconvert -L VERSION -g vers.o
>>>> linking kernel.debug
>>>> clock.o(.text+0x84c): In function `clkintr':
>>>> /usr/src/sys/x86/isa/clock.c:189: undefined reference to
>>>> `cyclic_clock_func'
>>>>
>>>> And upon inspection of clock.c:
>>>> #ifdef KDTRACE_HOOKS
>>>> #include <sys/dtrace_bsd.h>
>>>> #endif
>>>>
>>>> And in clkintr():
>>>> #ifdef KDTRACE_HOOKS
>>>>        /*
>>>>         * If the DTrace hooks are configured and a callback function
>>>>         * has been registered, then call it to process the high speed
>>>>         * timers.
>>>>         */
>>>>        int cpu = PCPU_GET(cpuid);
>>>>        if (cyclic_clock_func[cpu] != NULL)
>>>>                (*cyclic_clock_func[cpu])(frame);
>>>> #endif
>>>>
>>>>
>>>> It seems for some odd reason that <sys/dtrace_bsd.h> is being forgotten
>>>> when
>>>> it comes time for linking ? What is going on here ?
>>>>
>>>> Id like to just remove the ifdef's for KDTRACE_HOOKS just to get the
> build
>>>> to
>>>> finish but in the case that I want to build another kernel without dtrace
> I
>>>> would have to add them back. Anyone have a better fitting solution to
> this
>>>> ?
>>>>
>>>> Would it be just as good to re-ifdef this to ?WITH_CTF? instead.
>>>>
>>>> Anyway... this is latest code from stable/8 on i386. And yes options
>>>> KDTRACE_HOOKS is in the kernel config.
>>>>
>>>> And the command that caused all this:
>>>> ( make kernel WITH_CTF=1 )
>>>>
>>>
>>> In light of this I decided to just remove the effected section of clock.c
>>> and move forward as this part of the kernel with DTrace is not what I am
>>> looking into.
>>>
>>> Attached is a small patch that removes it in case someone else comes
>>> across the same thing and needs a quick workaround.
>>>
>>
>> To my best belief the cause is this i386 build is being done without
>> "device apic" that includes I/O APIC (local_apic.c) which defines in a
>> ifdef KDTRACE_HOOKS ( cyclic_clock_func_t cyclic_clock_func[MAXCPU]; ).
>> Since the lack of I/O APIC being used, sys/x86/isa/clock.c needs its own
>> definition of the same cyclic_clock_func, so I have added this in the same
>> way that its implemented in local_apic.c to clock.c and the build succeeds
>> and is usable.
>>
>> Would it be best to just move cyclic_clock_func definition to dtrace_bsd.h
>> instead ? and remove the definition in local_apic.c ?
>
> I think DTrace requires the local APIC to work as it hooks directly into the
> local APIC timer interrupt IIRC.
>

I was starting to think that myself but after adding the above to clock.c 
it fixed the issue I was seeing. It appears that clock.c is providing 
enough of a interrupt to at least hotkernel and dtruss + procsystime.

hotkernel
...
kernel`bzero                                               28   0.1%
kernel`copyout                                             31   0.1%
kernel`syscallret                                          31   0.1%
kernel`uma_zfree_arg                                       33   0.1%
kernel`fget_unlocked                                       35   0.1%
kernel`cpu_fetch_syscall_args                              37   0.1%
kernel`sopoll_generic                                      39   0.1%
kernel`uma_zalloc_arg                                      41   0.1%
kernel`poll                                                44   0.1%
kernel`copyin                                              48   0.1%
kernel`soreceive_generic                                   60   0.1%
kernel`kern_select                                         66   0.2%
kernel`syscallenter                                        93   0.2%
kernel`sched_idletd                                       135   0.3%
kernel`spinlock_exit                                      337   0.8%
kernel`acpi_cpu_c1                                      40525  95.1%

I would say at least for the tests I ran with this so far it fixes it¿

procsystime
...
Elapsed Times for all processes,

          SYSCALL          TIME (ns)
          getppid              13579
        sigreturn              18646
            fcntl              27752
           getpid              36201
            fstat              45574
            close              47142
           socket              55193
       sigpending              86178
             mmap             111586
          connect             171967
      swapcontext             224511
            write             360017
      sigprocmask             369920
        setitimer             409114
        sigaction             650495
           writev             667841
     gettimeofday            1480759
            ioctl            3403788
             stat            4044830
    clock_gettime            4704770
         __sysctl            7789725
             read         9526207068
           kevent        10024305765
         _umtx_op        10142262643
             poll        15037340342
           select        34427328326

And a simple run of a d.d from example:
vfs:namecache:enter:done
{

         @distribution = quantize(strlen((string)arg1));
}

            value  ------------- Distribution ------------- count
                1 |                                         0
                2 |@@@@@@@@@@@@@@                           20
                4 |@@@@@@@@@@@@@@@@@@                       25
                8 |@@@@@@@@                                 12
               16 |                                         0


-- 

  Regards,

  J. Hellenthal
  (0x89D8547E)
  JJH48-ARIN