On Fri, Jul 7, 2017 at 10:27 AM, Cillian O'Donnell <cpodonne...@gmail.com> wrote:
> On 7 July 2017 at 03:58, Joel Sherrill <j...@rtems.org> wrote: > > > > > > On Jul 6, 2017 9:20 PM, "Chris Johns" <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>> 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. > > > > > > That could replace the use of NM. Could it also replace objdump? > > > > It looks like now that he has problems with the Couverture trace and > running > > in parallel which is independent. > > I ran rtems-test single threaded --jobs=1 and it locked up on the > first executable base_sp.exe of the covoar run. > > information->inactive_per_block[ block ] = information->allocation_size; > 4000c154: c4 16 20 14 lduh [ %i0 + 0x14 ], %g2 > 4000c158: c6 06 20 30 ld [ %i0 + 0x30 ], %g3 > > Just stops here with no error message. So maybe the IO Error is about > parallel tasks, I'd have to run it a few more times to be sure. > This looks like qemu isn't completing the execution of the RTEMS application. > > Also I did compare qemu-traces.h with couverture's and there was a few > changes to be made. It matches exactly now and I rebuilt covoar. It > still lock's up as above though. > > Also I tried to build qemu-dump-traces like you mentioned Joel waf > builds and doesn't complain about anything but there's no executable > in the build directory, should there be? How does qemy-dump-traces > work? The waf build looks like this: > > 127 bld.program(target = 'qemu-dump-trace', > 128 source = ['qemu-dump-trace.c'], > 129 use = 'ccovoar', > 130 cflags = ['-O2', '-g'], > 131 includes = ['.']) > > When you get a qemu-dump-trace executable, it is invoked like ..../qemu-dump-trace tracefile1... tracefileN This is good to see if the information looks reasonable given the program you are looking at the trace of. It is a very simple program and does **NOT** contain any source code from covoar so it doesn't prove that covoar is reading the trace correctly -- just that the basic look of the trace file is OK given the hand inspection. > > > > As a test, can you run all tests with coverage disabled? > > Yes the full testsuite runs fine with coverage disabled, it's only the > post testsuite covoar runs that ever run into trouble > If you comment out the execution of covoar in rtems-tester does it still hang. Everything you post shows a SPARC trace which isn't from covoar execution. Just print "would run covoar here and show the command line" :) We need to be sure that an rtems-tester run completes with couverture with both coverage tracing on and off. Without it invoking covoar. Then you can run covoar by hand after using the output. > > > > It would be helpful if running the tests and running covoar could be > > separate. Easier to debug. > > This would be handy to not have to wait for the full testsuite to run > every time to check if something has worked or not. I'm not sure how > to separate the covoar part though. > Save the configuration file from a single covoar run and print the command line. You can save a build tree, trace files, etc. and just run covoar by hand repeatedly. > > > > > >> > 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. 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. > > > > > >> 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? > > > > > > Chris > > > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
