| 103 | 103 | * I spent the week working on the 'trace block inconsistent with coverage map' problem. For all cases the trace block is 36 bytes and the coverage map is 24 bytes. I've checked 2 examples where this occurs base_sp.exe and ticker.exe. The couverture trace and the objdump look identical so theres no difference in the generation of these. The start addresses of the block always match, so it is how the end of the block is determined is the problem. From the RTEMS side, each line of the objdump is scanned until 3 items are found for a regex that determines if a new function is on this line. All 3 items match for lines that look like 4000c2cc <_Objects_Get_information_id>: and the section in question has two such lines the first which is 24 bytes until we reach this 4000c2e4 <_Objects_Get_information>: but couverture carries on until a nop at 36 bytes which creates the discrepancy. The couverture op code is 0x12 in both examples which means 'branch fully executed' and 'branch not taken'. I'm trying to find an example with op code 0x11 which would mean the 'branch was taken' and see if that changes how couverture chooses the end of the block, possibly libtests/dl04 or dl05 which I'm looking at, at the moment. Next week I'll be visiting family from Friday to Tuesday, which I mentioned before, so not a whole lot will get done this week. |
![[RTEMS Logo]](/images/logo.png){kind=logo}
