gdb設定一個函式,出現4個斷點的原因

今天在vmlinux上設定斷點的時候出現4個地址, 超乎認知了, 仔細得看了一下原因

(gdb) b sched_clock
Breakpoint 1 at 0xffffffff8101cf00: sched_clock. (4 locations)
(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         y     0xffffffff8101cf00 in sched_clock at arch/x86/kernel/tsc.c:75
1.2                         y     0xffffffff8101d4fd in tsc_save_sched_clock_state at arch/x86/include/asm/paravirt.h:192
1.3                         y     0xffffffff8101d555 in tsc_restore_sched_clock_state at arch/x86/include/asm/paravirt.h:192
1.4                         y     0xffffffff810b5c30 in sched_clock at kernel/sched/clock.c:71

仔細得看了一下第一個斷點, 正常

unsigned long long sched_clock(void)
{
    return paravirt_sched_clock();
}
(gdb) disassemble sched_clock
Dump of assembler code for function sched_clock:
   0xffffffff8101cf00 <+0>:     push   %rbp
   0xffffffff8101cf01 <+1>:     mov    %rsp,%rbp
-------------------------------------------------------------------------------
   0xffffffff8101cf04 <+4>:     callq  *0xffffffff81a463c0
-------------------------------------------------------------------------------
   0xffffffff8101cf0b <+11>:    pop    %rbp
   0xffffffff8101cf0c <+12>:    retq   
End of assembler dump.

看第二個使用的地方tsc_save_sched_clock_state

void tsc_save_sched_clock_state(void)
{
    if (!sched_clock_stable())
        return;

    cyc2ns_suspend = sched_clock();
}

(gdb) disassemble tsc_save_sched_clock_state 
Dump of assembler code for function tsc_save_sched_clock_state:
   0xffffffff8101d4f0 <+0>:     push   %rbp
   0xffffffff8101d4f1 <+1>:     mov    %rsp,%rbp
   0xffffffff8101d4f4 <+4>:     callq  0xffffffff810b5d30 <sched_clock_stable>
   0xffffffff8101d4f9 <+9>:     test   %eax,%eax
   0xffffffff8101d4fb <+11>:    je     0xffffffff8101d50b <tsc_save_sched_clock_state+27>
------------------------------------------------------------------------------
   0xffffffff8101d4fd <+13>:    callq  *0xffffffff81a463c0
------------------------------------------------------------------------------
   0xffffffff8101d504 <+20>:    mov    %rax,0xd1c935(%rip)        # 0xffffffff81d39e40 <cyc2ns_suspend>
   0xffffffff8101d50b <+27>:    pop    %rbp
   0xffffffff8101d50c <+28>:    retq   
End of assembler dump.

可以看到函式tsc_save_sched_clock_state在呼叫sched_clock的時候, 因為tsc_save_sched_clock_state和sched_clock在同一個c檔案裡面, 就直接把函式sched_clock的肉嵌入進來了, 沒有直接呼叫sched_clock, 為了和c語言的邏輯保持一致, 所以這些地方都需要被打上斷點

第三個tsc_restore_sched_clock_state和第二個是一樣的

第4個的程式碼是這樣的

unsigned long long __attribute__((weak)) sched_clock(void)
{
    return (unsigned long long)(jiffies - INITIAL_JIFFIES)
                    * (NSEC_PER_SEC / HZ);
}

是個弱符號, 但是從以前的知識來說, 弱符號在編譯的時候會被強符號幹掉, 在從o檔案連線成elf檔案的時候就沒了, 為什麼這個時候又出現了呢

readelf -s vmlinux |grep sched_clock$
  9679: ffffffff819e8690    16 OBJECT  LOCAL  DEFAULT    8 __ksymtab_sched_clock
  9680: ffffffff819fc66a    12 OBJECT  LOCAL  DEFAULT   11 __kstrtab_sched_clock
  9681: ffffffff819f7ac0     8 OBJECT  LOCAL  DEFAULT   10 __kcrctab_sched_clock
 66460: ffffffff8101ce80   123 FUNC    GLOBAL DEFAULT    1 native_sched_clock
 67482: 000000003a26ed11     0 NOTYPE  GLOBAL DEFAULT  ABS __crc_sched_clock
 72418: ffffffff8101cf00    13 FUNC    GLOBAL DEFAULT    1 sched_clock

可以看到其實符號表裡面只有一個sched_clock符號, 從地址上可以確定是gdb中的第一個符號, 那麼這些資訊存在哪裡呢

一個有可能的猜想就是在debug section裡面

把vmlinux的debug section去掉看看

$strip --strip-debug vmlinux.cp

gdb vmlinux.cp

(gdb) i b
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0xffffffff8101cf04 <sched_clock+4>

可以只剩一個了, 所以原因是vmlinux中的debug section的資訊符號了符號表的資訊, 這樣看起來, 在gdb vmlinux的時候, 去掉debug section的時候, 有些函式呼叫資訊會丟失, 光依賴符號表也不準確