Re: Question for coverage report

=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes:
> On 2025-Oct-21, Jacob Champion wrote:
>> Are you able to double-check the compiler invocation for pgoutput.c?

> Yep -- it does get -O0.  Is there some other flag this is missing?

I think this is probably a gcc artifact.  I looked at the assembly
code generated in coverage mode, which on my setup is like

$ gcc -std=gnu11 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels
-Wmissing-format-attribute-Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security
-fno-strict-aliasing-fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g -O0
-fprofile-arcs-ftest-coverage -fPIC -fvisibility=hidden -I../../../../src/include -D_GNU_SOURCE -S pgoutput.c 

In pgoutput.s I find

    .loc 9 1494 7
    movq    -120(%rbp), %rax
    movq    %rax, %rdi
    call    is_publishable_relation@PLT
    movl    %eax, %edx
# this is evidently incrementing the count for line 1494:
    movq    8+__gcov0.pgoutput_change(%rip), %rax
    addq    $1, %rax
    movq    %rax, 8+__gcov0.pgoutput_change(%rip)
    .loc 9 1494 6
    movl    %edx, %eax
    xorl    $1, %eax
    .loc 9 1494 5
    testb    %al, %al
    je    .L275
# this is evidently incrementing the count for line 1495:
    movq    16+__gcov0.pgoutput_change(%rip), %rax
    addq    $1, %rax
    movq    %rax, 16+__gcov0.pgoutput_change(%rip)
    .loc 9 1495 3
    jmp    .L274
.L275:
    .loc 9 1503 10
    movq    -40(%rbp), %rax
    movzbl    24(%rax), %eax
    .loc 9 1503 5
    testb    %al, %al
    je    .L277
# this is evidently incrementing the count for line 1504:
    movq    24+__gcov0.pgoutput_change(%rip), %rax
    addq    $1, %rax
    movq    %rax, 24+__gcov0.pgoutput_change(%rip)
    .loc 9 1504 15
    movq    -128(%rbp), %rax
    movq    16(%rax), %rax
    .loc 9 1504 7
    movl    4(%rax), %eax
    movl    %eax, -4(%rbp)
.L277:
    .loc 9 1506 13
    movq    -120(%rbp), %rdx
    movq    -40(%rbp), %rax
    movq    %rdx, %rsi
    movq    %rax, %rdi
    call    get_rel_sync_entry
    movq    %rax, -56(%rbp)
# this is evidently incrementing the count for line 1506:
    movq    32+__gcov0.pgoutput_change(%rip), %rax
    addq    $1, %rax
    movq    %rax, 32+__gcov0.pgoutput_change(%rip)

So what I am seeing is that there is not actually a separate counter
for line 1503.  It must be that gcov is told that's part of the same
basic block as line 1494 and should be displayed with the same count.

Another thing that I had not known before is that the count associated
with a function-call line is incremented after return, so that no
count will accrue if the function is called but throws an error.

Now, I'm sure Alvaro's machine is using a different gcc version, and
maybe it doesn't act exactly like this.  But I think essentially what
is happening is that there is only one counter for each chunk of code
that the compiler regards as a basic block, and the block boundaries
are not as intuitive as you might think.

            regards, tom lane