如何为模板函数调用解释gcov结果

Question

Question 1: How do I decipher the function names, like _ZN21CircularBufferManager4readIlEEmPT_m ? I'm guessing the second character after "read" in those long function names (ie l, t, h, d) must have something to do with type. I use unsigned char, unsigned short, signed long, double.

Question 2: In line #227, I see 16 branches. Why 16? On the other hand, line #222 has 8 branches, which makes sense to me because 2 states (true or false) times 4 functions makes 8 branches.

        -:  216:    template<typename Type>
function _ZN21CircularBufferManager4readIlEEmPT_m called 2 returned 100% blocks executed 63%
function _ZN21CircularBufferManager4readItEEmPT_m called 2 returned 100% blocks executed 50%
function _ZN21CircularBufferManager4readIhEEmPT_m called 10 returned 100% blocks executed 94%
function _ZN21CircularBufferManager4readIdEEmPT_m called 8 returned 100% blocks executed 94%
       22:  217:    uint32 read(Type* data, uint32 element_count)
        -:  218:    {
       22:  219:        uint32 size(sizeof(Type)*element_count);
        -:  220:
       22:  221:        uint32 write_pos_alias(this->write_pos);
       22:  222:        if (this->read_pos > this->write_pos) {
branch  0 taken 0% (fallthrough)
branch  1 taken 100%
branch  2 taken 0% (fallthrough)
branch  3 taken 100%
branch  4 taken 20% (fallthrough)
branch  5 taken 80%
branch  6 taken 13% (fallthrough)
branch  7 taken 88%
        3:  223:            write_pos_alias += this->allocated_size;
        -:  224:        }
        -:  225:        assert(write_pos_alias >= this->read_pos);
       22:  226:        uint32 n(write_pos_alias - this->read_pos); // number of bytes to reach the write position
       22:  227:        if (n==0 && this->stored_count==0) // <=> buffer is empty
branch  0 taken 50% (fallthrough)
branch  1 taken 50%
branch  2 taken 100% (fallthrough)
branch  3 taken 0%
branch  4 taken 0% (fallthrough)
branch  5 taken 100%
branch  6 never executed
branch  7 never executed
branch  8 taken 30% (fallthrough)
branch  9 taken 70%
branch 10 taken 0% (fallthrough)
branch 11 taken 100%
branch 12 taken 38% (fallthrough)
branch 13 taken 63%
branch 14 taken 0% (fallthrough)
branch 15 taken 100%
        -:  228:        {
        -:  229:            // no data read
        1:  230:            return 0;
        -:  231:        }
       21:  232:        else if (0<n && n<size) // read is stopped before read_pos crosses over write_pos.
branch  0 taken 100% (fallthrough)
branch  1 taken 0%
branch  2 taken 0% (fallthrough)
branch  3 taken 100%
branch  4 taken 100% (fallthrough)
branch  5 taken 0%
branch  6 taken 0% (fallthrough)
branch  7 taken 100%
branch  8 taken 70% (fallthrough)
branch  9 taken 30%
branch 10 taken 14% (fallthrough)
branch 11 taken 86%
branch 12 taken 63% (fallthrough)
branch 13 taken 38%
branch 14 taken 20% (fallthrough)
branch 15 taken 80%
        -:  233:        {
        2:  234:            return read(reinterpret_cast<uint8*>(data), n); //less data than required.
call    0 never executed
call    1 never executed
call    2 returned 100%
call    3 returned 100%
        -:  235:        }
        -:  236:        // It is guaranteed here and below that read_pos never crosses-over write_pos.
        -:  237:
       19:  238:        if (this->read_pos + size > this->allocated_size) // going beyond the end of buffer
branch  0 taken 0% (fallthrough)
branch  1 taken 100%
branch  2 taken 0% (fallthrough)
branch  3 taken 100%
branch  4 taken 11% (fallthrough)
branch  5 taken 89%
branch  6 taken 43% (fallthrough)
branch  7 taken 57%
        -:  239:        {
        4:  240:            uint32 n(this->allocated_size - this->read_pos); // number of bytes to reach the end of buffer
        -:  241:            return this->read(reinterpret_cast<uint8*>(data), n)
        4:  242:                 + this->read(reinterpret_cast<uint8*>(data)+n, size-n);
call    0 never executed
call    1 never executed
call    2 never executed
call    3 never executed
call    4 returned 100%
call    5 returned 100%
call    6 returned 100%
call    7 returned 100%
        -:  243:        }
       15:  244:        memcpy(reinterpret_cast<void*>(data), reinterpret_cast<void*>(this->buf+this->read_pos), size);
       15:  245:        incrementReadPos(size);
call    0 returned 100%
call    1 returned 100%
call    2 returned 100%
call    3 returned 100%
       15:  246:        return size;
        -:  247:    }

Answer 1

For your first question, you can pipe this output through the c++filt command to demangle the identifiers.

For your second question, apparently gcov doesn't care if the false gets short circuited, it still counts three ways to get to false, and only one way to get to true.

• true => n==0 && this->stored_count==0
• false => n!=0 && this->stored_count==0
• false => n!=0 && this->stored_count!=0
• false => n==0 && this->stored_count!=0

Since you expand your template function 4 ways, that makes sixteen.