I just want to give an update to my understanding of this problem as I'm not sure I was clear enough in the IRC meeting. We ended up talking about nops but I think the problem is something else.
So when there is a successful covoar run, it will generate a report but also finish with this message. *** Trace block is inconsistent with coverage map *** Trace block (0x4000c2cc - 0x4000c2ec) for 36 bytes *** Coverage map /home/cpod/coverage_test/leon3/coverage/base_sp.exe.cov ----------------------------- The coverage map is 24 bytes: (gdb) p/x *entry $2 = {pc = 0x4000c2cc, size = 0x24, op = 0x12} ----------------------------- The disassembly block in question is: 4000c2cc <_Objects_Get_information_id>: 4000c2cc: 83 32 20 18 srl %o0, 0x18, %g1 Objects_Information *_Objects_Get_information_id( Objects_Id id ) { return _Objects_Get_information( 4000c2d0: 93 32 20 1b srl %o0, 0x1b, %o1 4000c2d4: 90 08 60 07 and %g1, 7, %o0 4000c2d8: 82 13 c0 00 mov %o7, %g1 4000c2dc: 40 00 00 02 call 4000c2e4 <_Objects_Get_information> 4000c2e0: 9e 10 40 00 mov %g1, %o7 4000c2e4 <_Objects_Get_information>: Objects_Information *_Objects_Get_information( Objects_APIs the_api, uint16_t the_class ) { 4000c2e4: 9d e3 bf a0 save %sp, -96, %sp Objects_Information *info; int the_class_api_maximum; if ( !the_class ) 4000c2e8: 80 a6 60 00 cmp %i1, 0 4000c2ec: 02 80 00 19 be 4000c350 <_Objects_Get_information+0x6c> 4000c2f0: 01 00 00 00 nop ------------------------------------ I have checked this out on base_sp.exe and ticker.exe where the same inconsistency appears in both. Couverture-QEMU decides the trace block encompasses that entire block Whereas from the covoar side the objdump is always processed line by line and a regex is checked to determine what kind of line it is. 408 items = sscanf( 409 inputBuffer, 410 "%x <%[^>]>%c", 411 &offset, symbol, &terminator1 412 ); If there is a match for all 3 items then this is a new function 415 if ((items == 3) && (terminator1 == ':')) { 416 417 endAddress = executableInformation->getLoadAddress() + offset - 1; So the objdump above is always processed as 2 seperate sections. One for: 4000c2cc <_Objects_Get_information_id>: And one for: 4000c2e4 <_Objects_Get_information>: The size from Objects_Get_information_id to Objects_Get_information is 24 bytes which is the coverage map. The size of both functions combined is 36 bytes which is the Couverture trace block. Couverture could possibly be doing something more sophisticated to determine the end of the block or it could just be wrong. So the next thing I'm doing is figuring out exactly how Couverture is processing this. For both cases the trace op code is 0x12 which means 'Branch fully executed' and 'Branch not taken'. I'm trying to find one with op code 0x11 which would mean the 'branch is taken' and possibly it might be processed differently in this case. The only place both these functions appear in the source is libtests/dl04 and dl05. I'm checking those out at the moment. Thanks, Cillian. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel