Comment # 6 on bug 1224402 from Miroslav Beneš

Thanks. So it seems that... (thanks Petr Pavlu for helping out because it is
really a strange thing)

    adc1:       4c 8b 05 00 00 00 00    mov    0x0(%rip),%r8        # adc8
<nv_register_procfs+0x218>
                        adc4: R_X86_64_PC32     .bss+0x1284
    adc8:       48 c7 c1 00 00 00 00    mov    $0x0,%rcx
                        adcb: R_X86_64_32S      .rodata+0x420
    adcf:       48 89 c2                mov    %rax,%rdx
    add2:       be 24 81 00 00          mov    $0x8124,%esi
    add7:       e8 00 00 00 00          call   addc <nv_register_procfs+0x22c>
                        add8: R_X86_64_PC32     proc_create_data-0x4
    addc:       0f 1f 40 00             nopl   0x0(%rax)

is just dead code. Originally it comes from

    for (i = 0; __nv_patches[i].short_description; i++)
    {
        nv_procfs_add_text_file(proc_nvidia_patches,
            __nv_patches[i].short_description, __nv_patches[i].description);
    }

where __nv_patches is a global array initialized as

static struct {
                const char *short_description;
                const char *description;
              } __nv_patches[] = {
{ ((void *)0), ((void *)0) } };

The dead code is nv_procfs_add_text_file() inlined (it contains just the call
to proc_create_data()).

The compiler knows that the loop does not exist and it is optimized out. The
call site (from the "loop") looks like

    aced:       48 8b 3d 00 00 00 00    mov    0x0(%rip),%rdi        # acf4
<nv_register_procfs+0x144>
                        acf0: R_X86_64_PC32     .bss+0x127c
    acf4:       48 85 ff                test   %rdi,%rdi
    acf7:       0f 85 c4 00 00 00       jne    adc1 <nv_register_procfs+0x211>

Meaning that the jump never happens (the array contains just zeros). However it
is all left there. No idea why.

So objtool basically reports a correct thing.

Martin, does it ring a bell? Could you shed some light on this?