Gcov报告分支机构的普通函数调用

Question

我使用gcov获取我们项目的代码覆盖率，但它经常报告50％的条件覆盖率为普通函数调用。如果该函数使用任何参数或返回任何数据，它没有任何区别。我在Jenkins使用gcovr和Cobertura，但是一个简单的gcov文件给出了相同的结果。 下面附带实际测试的代码以及所有采用gcov格式的桩函数。 任何想法为什么gcov威胁这些函数作为分支调用？

 -: 146:/*****************************************************************************/ 
function _Z12mw_log_clearv called 2 returned 100% blocks executed 100% 
     2: 147:void mw_log_clear(void) 
     2: 147-block 0 
     -: 148:{ 
     2: 149: uint8_t i = 0; 
     2: 150: uint8_t clear_tuple[EE_PAGE_SIZE] = { 0xff }; 
     -: 151:  
     66: 152: for (i = 0; i < (int16_t)EE_PAGE_SIZE; i++) 
     2: 152-block 0 
     64: 152-block 1 
     66: 152-block 2 
branch 0 taken 97% 
branch 1 taken 3% (fallthrough) 
     -: 153: { 
     64: 154:  clear_tuple[i] = 0xff; 
     -: 155: } 
     -: 156:  
     -: 157: /* Write pending data */ 
     2: 158: mw_eeprom_write_blocking(); 
     2: 158-block 0 
call 0 returned 100% 
branch 1 taken 100% (fallthrough) <---- This is a plain function call, not a branch 
branch 2 taken 0% (throw)   <---- This is a plain function call, not a branch 
     -: 159:  
     26: 160: for (i = 0; i < (RESERVED_PAGES_PER_PAREMETER_SET - POPULATED_PAGES_PER_PAREMETER_SET); i++) 
     2: 160-block 0 
     24: 160-block 1 
     26: 160-block 2 
branch 0 taken 96% 
branch 1 taken 4% (fallthrough) 
     -: 161: { 
     25: 162:  if (status_ok != mw_eeprom_write(LOG_TUPLE_START_ADDRESS + i * EE_PAGE_SIZE, clear_tuple, sizeof(clear_tuple))) 
     25: 162-block 0 
call 0 returned 100% 
branch 1 taken 100% (fallthrough) <---- This is a plain function call, not a branch 
branch 2 taken 0% (throw)   <---- This is a plain function call, not a branch 
     25: 162-block 1 
branch 3 taken 4% (fallthrough) 
branch 4 taken 96% 
     -: 163:  { 
     1: 164:   mw_error_handler_add(mw_error_eeprom_busy); 
     1: 164-block 0 
call 0 returned 100% 
branch 1 taken 100% (fallthrough) <---- This is a plain function call, not a branch 
branch 2 taken 0% (throw)   <---- This is a plain function call, not a branch 
     1: 165:   break; 
     1: 165-block 0 
     -: 166:  } 
     -: 167:   
     24: 168:  mw_eeprom_write_blocking(); 
     24: 168-block 0 
call 0 returned 100% 
branch 1 taken 100% (fallthrough) <---- This is a plain function call, not a branch 
branch 2 taken 0% (throw)   <---- This is a plain function call, not a branch 
     -: 169: } 
     2: 170:} 
     2: 170-block 0 
     -: 171: 
     -: 172:/*****************************************************************************/ 

/************************************** ***********************************/

void mw_eeprom_write_blocking(void) 
{ 
    stub_data.eeprom_write_blocking_calls++; 
} 

/****** ************************************************** *********************/

void mw_error_handler_add(mw_error_code_t error_code) 
{ 
    EXPECT_EQ(error_code, stub_data.expected_error_code); 
    stub_data.registered_error_code = error_code; 
} 

/******************** ************************************************** *******/

status_t mw_eeprom_write(
     const uint32_t eeprom_start_index, 
     void *const source_start_address, 
     const uint32_t length) 
{ 
    stub_data.eeprom_write_start_index = eeprom_start_index; 
    stub_data.eeprom_write_length = length; 
    stub_data.eeprom_write_called = true; 

    EXPECT_NE(NULL, (uint32_t)source_start_address); 
    EXPECT_NE(0, length); 
    EXPECT_LE(eeprom_start_index + length, EEPROM_SIZE); 

    if (status_ok == stub_data.eeprom_write_status) 
     memcpy(&stub_data.eeprom[eeprom_start_index], source_start_address, length); 

    return stub_data.eeprom_write_status; 
} 

Answer 1

解决！

发现在这个线程的答案： Why gcc 4.1 + gcov reports 100% branch coverage and newer (4.4, 4.6, 4.8) reports 50% for "p = new class;" line?

好像gcov的反应对这些函数调用一些“看不见”的异常处理代码，因此添加“-fno-例外”到g ++的所有这些失踪的分支机构消失。