Cannot taken branch to measure code coverage on S32R294

[sonvungoc]

Hi,

I am measure code coverage for some APIs relative ternary operator. Saw debugger cannot recognize branch when ternary operators are used and missing e_b also. It gives bad results measure code coverage. Please help me check it. My debugger as below:

• Function not taken decision:

• Function foo1 not taken decisionFunction foo2 not taken decisionFunction foo4 not taken decisionFunction foo5 not taken decisionFunction foo5 not taken decision
• Funtion taken decision:

        Funtion foo3 taken decision

My code test as below:

///  typedefs to fix MISRA DIR4.6
typedef uint8_t BOOL;
#define TRUE ((uint8_t)1u)
#define FALSE ((uint8_t)0u)

typedef uint32_t FOO_ERRCODE;

#define FOO_ERR_NOERROR                  (0u)
#define FOO_ERR_INPUTOUTOFRANGE          (0x50001u)
#define FOO_ERR_INPUTOUTOFRANGE_2        (0x1u)

uint8_t foo1(uint8_t input1);
BOOL foo2(BOOL input2);
FOO_ERRCODE foo3(uint32_t input3);
FOO_ERRCODE foo4(uint32_t input4);
FOO_ERRCODE foo5(float32_t SeqInterval);

uint8_t foo1(uint8_t input1)
{
    uint8_t output1 = 0u;

    output1 = (input1 == 1u) ? 0u : 1u;

    return output1;
}

BOOL foo2(BOOL input2)
{
    BOOL output2 = FALSE;

    output2 = (input2 == TRUE) ? FALSE : TRUE;

    return output2;
}

FOO_ERRCODE foo3(uint32_t input3)
{
    FOO_ERRCODE errodeCode = FOO_ERR_NOERROR;

    errodeCode = (input3 > 32) ? FOO_ERR_NOERROR : FOO_ERR_INPUTOUTOFRANGE;

    return errodeCode;
}

FOO_ERRCODE foo4(uint32_t input4)
{
    FOO_ERRCODE errodeCode = FOO_ERR_NOERROR;

    errodeCode = (input4 > 32) ? FOO_ERR_NOERROR : FOO_ERR_INPUTOUTOFRANGE_2;

    return errodeCode;
}

FOO_ERRCODE foo5(float32_t SeqInterval)
{
    FOO_ERRCODE errodeCode = FOO_ERR_NOERROR;
    uint64_t tmpSeqInterval;

    tmpSeqInterval = (uint64_t)lroundf(SeqInterval * 1000.0f / 25.0f);
    if ((tmpSeqInterval >= 1u) && (tmpSeqInterval < 0xFFFFFFFFu))
    {
        errodeCode = FOO_ERR_NOERROR;
    }
    else
    {
        errodeCode = FOO_ERR_INPUTOUTOFRANGE;
    }

    return errodeCode;
}

void main(void)
{
    foo1(1u);
    foo1(0u);

    foo2(TRUE);
    foo2(FALSE);

    foo3(35u);
    foo3(25u);

    foo4(35u);
    foo4(25u);

    foo5(10u);
    foo5(0u);
    foo5(0xFFFFFFFFu);
}

My tool and enviroment:

• Compiler Versions: 

     GNU Compiler Collection - GCC Version 4.9.4 20160726

• SW Version:

- S32 Design Studio, version 2.1, Build ID 190624 with S32R294 development package version 2.1.0

- Lauterbach Trace32 PowerView for PowerPC, Version N.2021.06.000136240

• HW Version:

- EVB S32R294RRU2 

[petervlna]

Hello,

I am not sure what is the issue here.

Saw debugger cannot recognize branch when ternary operators are used and missing e_b also.

Nor I see missing branch operation in your post. Is this issue with the translation or debugger processing?

Could you explain it in more detail?

Best regards,

Peter

[sonvungoc]

Hi Peter,

In my driver have a lot of ternary operator are used, I am trying cover all ternary operator, almost them are taken 100% coverage report by TRACE32. Some ternary operator cannot taken, I sure I have unit test for cover them, but TRACE32 reported improper. Actually, I don't know root cause issue yet.
I checked assembly code by debug TRACE32. Saw ternary operator are not taken 100% coverage have not command "e_b". Checked in ternary operator taken 100%, saw all of them have command "e_b".
I guess TRACE32 need command ""e_b" to measure code coverage.

[petervlna]

Hello,

what comes to my mind, is compiler translation.

Try to play with compiler optimizations, like no optimization at all , etc...

Debugger really displays only what is translated.

Also check output files form compilation to see if the translation corresponds with what you expect.

Best regards,

Peter

[rweiss]

For questions about TRACE32 please contact Lauterbach at https://support.lauterbach.com/

[sonvungoc]

Hi Reinhard,

I raised to Lauterbach team. But this issue still resolved yet

[rweiss]

Please write to Lauterbach again and include a link to this thread, so we can combine your requests.

Regards,
Reinhard