Changes between Version 99 and Version 100 of GSoC/2017

Timestamp:

07/12/17 14:44:40 (7 years ago)

Author:

Cillian O'Donnell

Comment:

--

GSoC/2017

@@ -100 +100 @@
 * July 5:
   * Coverage is now running with RTEMS Tester and I have a Leon3 report for libscore.a set. There's some strange behaviour with covoar runs not always finishing and some missing Gcov files that I have detailed on devel. Apart from that it works quite well. I also found some post gsoc work by 2015 student Hermann that cleaned up hard-coded paths and other things, so I've sorted through them added what was still usable. Next week I'll try and get more detailed reports by adding more libraries to the symbol sets and fix the above issues if they need fixing. Also if those problems don't turn out to be too significant, I could start posting patches of what I have and begin the merging effort.
+* July 12:
+  * 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 "%x <%[^>]>%c", &offset, symbol, &terminator1. 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.
 
 == Denis Obrezkov ==