Changes between Version 106 and Version 107 of GSoC/2017


Ignore:
Timestamp:
Jul 19, 2017, 2:38:29 PM (2 years ago)
Author:
Cillian O'Donnell
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2017

    v106 v107  
    102102* July 12:
    103103  * 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.
     104* July 19:
     105  * Not much change in status this week as I was on holidays for most of it. The trace block inconsistent message has been removed as it has been deemed as too restrictive a check and unneccesary. So for this week that leaves the issues Chris mentioned with the merging effort which I am working on right now and the intermittent lock up behaviour.
    104106
    105107== Denis Obrezkov ==