On 07/07/2017 12:58, Joel Sherrill wrote: > On Jul 6, 2017 9:20 PM, "Chris Johns" <chr...@rtems.org > <mailto:chr...@rtems.org>> wrote: > > 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> > > <mailto: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>> > > > <mailto: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 > <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. > > > That could replace the use of NM. Could it also replace objdump? >
Oh nm is being used. What is objdump being used for? > It looks like now that he has problems with the Couverture trace and running > in > parallel which is independent. > > As a test, can you run all tests with coverage disabled? > > It would be helpful if running the tests and running covoar could be separate. > Easier to debug. > > > > > 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. > > > When things work. I think there are two issues ahead of any issues because of > this. I cannot tell, I do not know how this all works. I was wondering if the fewer tools and files created the less room there is for error. > It has been on my wishlist but we need (1) to be to run all tests > successfully and (2) to be sure the Couverture trace is read correctly. > > > > > 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? > > > I do not know. I think it has the range but it would be straightforward I > think > to replace the use of NM. It may in the DWARF info which we do not have access to. > > Fwiw this thread needs to be split. There are multiple issues. > > This specific fragment I have created to address symbols? > > > If the issue is NM versus elf info, then it would help. Is there an RTEMS NM > based on the library? To load a symbol table you do this: https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n466 After that you have a symbol table you can use to get at the symbols. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
