On Jul 6, 2017 8:52 PM, "Chris Johns" <chr...@rtems.org> wrote:
On 07/07/2017 00:34, Joel Sherrill wrote: > On Thu, Jul 6, 2017 at 5:53 AM, Cillian O'Donnell <cpodonne...@gmail.com > <mailto:cpodonne...@gmail.com>> wrote: > It will ignore records when it thinks things are inconsistent. This can occur > when a method appears in two different executables and has different > sizes. The cause of this is usually padding at the end of the method so > the subsequent method in memory starts on a nice cache-line alignment. > The code tries to recognize the nops/padding at the end and ignore them. The code in the linked executable can be different to the object file. The linker does different things on different architectures and different link orders. We do not look at the .o files. The objdump output on exe files is used > When the padding inserted by ld changes or the objdump output being> parsed changes, covoar needs to be adjusted. This means fragile. Yes a bit. It has to be taught by architecture what padding LD puts in. But this doesn't change often or for no reason. Ian Taylor assured me years ago that the objdump output format was 5he most stable way to do this. > The ignored record message I saw is in the code that reads Couverture > trace records. The info in the record appears to be inconsistent with the > code to which it has been matched. Sorry, I do not understand why this difference is happening? I understand it is object files vs executable, what I do not understand is why the object files are being referenced, why not just use the executable? No .o is used. We haven't parsed couverture trace format in years. It could have changed. I **think** the message indicates that the qemu translation block is reported as longer than from the current instruction to the end of the method. The answer is to know the address range of the flagged trace block and what it corresponds to in the exe. Fwiw this thread needs to be split. There are multiple issues. Chris
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel