On 07/07/2017 12:10, Joel Sherrill wrote: > > > On Jul 6, 2017 8:52 PM, "Chris Johns" <chr...@rtems.org > <mailto: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> > > <mailto: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
I would like to see this changed to use: https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-symbols.h#n224 and to remove any objdump access. The toolkit will be much faster at loading a symbol table. > > 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. We have direct access to the EFL file and symbols. I see that as a better solution. > > 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. I wonder if ELF holds the size of the area or can the symbol table sorted by address produce the needed ranges? > Fwiw this thread needs to be split. There are multiple issues. This specific fragment I have created to address symbols? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
