Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 28 May 2018 at 00:49, Joel Sherrill  wrote:

> It sounds like great progress is being made but this thread is very long
> and I am losing track of what needs committing.
>
> We can start a new thread. :)

> Plus there is Chris' work to merge as well.
>
> How close is everything to moving back to master on the main repo?
>
> It seems to be close.
currently the only significant change that's needed
is the covoar update that I suggested. Other than that
there are a few #FIXMEs in the code that I added.
They are small issues and need a quick fix.
We can start a new thread with these topics as
it's very close to merging.

BTW, the coverage can now run from outside the
build directory as well :)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On Mon, 28 May 2018, 00:32 Cillian O'Donnell,  wrote:

>
>
> On Sun, 27 May 2018, 19:59 Vijay Kumar Banerjee, 
> wrote:
>
>> Hello,
>>
>> The support for letting users input specific symbols
>> for coverage analysis is now working in my
>> cov-tester-support branch
>>
>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support
>>
>
> Brilliant Vijay, I'll take a look today or tomorrow.
>
Thanks.
yeah, whenever you have time.

I want to propose a covoar update.
After the recent updates to covoar
it can run multiple sets from a single ini file. Earlier the build
directory was fed from the coverage script along with the set name. Which
doesn't seem to be needed anymore.
Can the support for storing the results of each symbol into a separate
folder be shifted to covoar ?
(Can covoar already do it ? I think no because the result directory with
set name is fed to covoar from the script)



>
>>
>> Please have a look into the code and test it.
>>
>> The user can input specific symbols with the --coverage
>> option to run covoar on specific symbols
>>
>> example :-
>>
>> --coverage=symbol1,symbol2,symbol3
>>
>> if no argument is provided then coverage will run for
>> all the symbols given in the symbol-sets.ini file .
>>
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 27 May 2018, 19:59 Vijay Kumar Banerjee, 
wrote:

> Hello,
>
> The support for letting users input specific symbols
> for coverage analysis is now working in my
> cov-tester-support branch
>
> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support
>

Brilliant Vijay, I'll take a look today or tomorrow.

>
>
> Please have a look into the code and test it.
>
> The user can input specific symbols with the --coverage
> option to run covoar on specific symbols
>
> example :-
>
> --coverage=symbol1,symbol2,symbol3
>
> if no argument is provided then coverage will run for
> all the symbols given in the symbol-sets.ini file .
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

Hello,

The support for letting users input specific symbols
for coverage analysis is now working in my
cov-tester-support branch

https://github.com/thelunatic/rtems-tools/tree/cov-tester-support

Please have a look into the code and test it.

The user can input specific symbols with the --coverage
option to run covoar on specific symbols

example :-

--coverage=symbol1,symbol2,symbol3

if no argument is provided then coverage will run for
all the symbols given in the symbol-sets.ini file .
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

Yeah I can see the difference in the objdump, it's optimized out though, so
not very helpful but the addresses do match the covoar output. That's with
-O2. I'll have to rebuild. Vijay you seeing the ... optimized out stuff

*

13338 4000c5ac <_Workspace_Allocate_or_fatal_error>:
13339 4000c5ac:   9d e3 bf a0 save  %sp, -96, %sp
13340 4000c5b0:   96 10 20 00 clr  %o3
13341 4000c5b4:   94 10 20 00 clr  %o2
13342 4000c5b8:   92 10 00 18 mov  %i0, %o1
13343 4000c5bc:   11 10 00 4a sethi  %hi(0x40012800), %o0
13344 4000c5c0:   7f ff e9 bf call  40006cbc
<_Heap_Allocate_aligned_with_bounda  ry>
13345 4000c5c4:   90 12 22 a0 or  %o0, 0x2a0, %o0 ! 40012aa0
<_Workspace_Area>
13346 4000c5c8:   80 a2 20 00 cmp  %o0, 0
13347 4000c5cc:   02 80 00 04 be  4000c5dc
<_Workspace_Allocate_or_fatal_error+0  x30>
13348 4000c5d0:   b0 10 00 08 mov  %o0, %i0
13349 4000c5d4:   81 c7 e0 08 ret
13350 4000c5d8:   81 e8 00 00 restore
13351 4000c5dc:   7f ff eb 5f call  40007358 <_Internal_error>
13352 4000c5e0:   90 10 20 03 mov  3, %o0
13353 4000c5e4:   01 00 00 00 nop
13354 ...
13355
13356 4000c600 :



**
23776 400162ac <_Workspace_Allocate_or_fatal_error>:
23777 400162ac:   9d e3 bf a0 save  %sp, -96, %sp
23778 400162b0:   96 10 20 00 clr  %o3
23779 400162b4:   94 10 20 00 clr  %o2
23780 400162b8:   92 10 00 18 mov  %i0, %o1
23781 400162bc:   11 10 00 d1 sethi  %hi(0x40034400), %o0
23782 400162c0:   7f ff e5 32 call  4000f788
<_Heap_Allocate_aligned_with_bounda  ry>
23783 400162c4:   90 12 22 20 or  %o0, 0x220, %o0 ! 40034620
<_Workspace_Area>
23784 400162c8:   80 a2 20 00 cmp  %o0, 0
23785 400162cc:   02 80 00 04 be  400162dc
<_Workspace_Allocate_or_fatal_error+0  x30>
23786 400162d0:   b0 10 00 08 mov  %o0, %i0
23787 400162d4:   81 c7 e0 08 ret
23788 400162d8:   81 e8 00 00 restore
23789 400162dc:   7f ff e7 1c call  4000ff4c <_Internal_error>
23790 400162e0:   90 10 20 03 mov  3, %o0
23791 400162e4:   01 00 00 00 nop
23792
23793 400162e8 :
*




On 21 May 2018 at 20:12, Vijay Kumar Banerjee 
wrote:

> On 22 May 2018 at 00:33, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 21, 2018, 1:54 PM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 23:07, Joel Sherrill  wrote:
>>>


 On Mon, May 21, 2018, 12:01 PM Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 21:42, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 21, 2018 at 10:13 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 20:37, Joel Sherrill  wrote:
>>>


 On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 17:39, Joel Sherrill  wrote:
>
>> CPU-rtems5-objdump
>>
>> sparc-rtems5-objdump worked  , thanks .
> I can see some mismatches in the disassembly .
>

 I'm building sparc now. What mismatches do you see?

 I started another thread for CSWTCH.*. That's not the type of
 mismatch Cillian
 worked on last summer. It is a symbol that isn't even code and
 shouldn't be
 in the symbol set.


>>> I saw the other thread . In sparc I'm getting CSWTCH.* in local text
>>> segment "t" .
>>>
>>
>> Grr... this may require us to toss out some symbol patterns that are
>> generated
>> by GCC.
>>
>>
>>>
>>> [lunatic@lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe |
>>> grep -i csw
>>> 40010c18 t CSWTCH.1
>>>
>>
>> I see this also on the sparc. On the i386, it is rodata.
>>
>>
>>>
>>> I followed the INFO messages for a mismatch in
>>> _Workspace_Allocate_or_fatal_error
>>>
>>> here's what I came up with
>>>
>>> --- capture.exe
>>> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d
>>> capture/capture.exe | grep "_Workspace_Allocate_or_fatal_error"
>>> 40010c5c: 40 00 15 8c call  4001628c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 400117ac: 40 00 12 b8 call  4001628c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 40011938: 40 00 12 55 call  4001628c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 40015c94: 40 00 01 7e call  4001628c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 4001628c <_Workspace_Allocate_or_fatal_error>:
>>> 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

On Mon, May 21, 2018 at 2:12 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> On 22 May 2018 at 00:33, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 21, 2018, 1:54 PM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 23:07, Joel Sherrill  wrote:
>>>


 On Mon, May 21, 2018, 12:01 PM Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 21:42, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 21, 2018 at 10:13 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 20:37, Joel Sherrill  wrote:
>>>


 On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 17:39, Joel Sherrill  wrote:
>
>> CPU-rtems5-objdump
>>
>> sparc-rtems5-objdump worked  , thanks .
> I can see some mismatches in the disassembly .
>

 I'm building sparc now. What mismatches do you see?

 I started another thread for CSWTCH.*. That's not the type of
 mismatch Cillian
 worked on last summer. It is a symbol that isn't even code and
 shouldn't be
 in the symbol set.


>>> I saw the other thread . In sparc I'm getting CSWTCH.* in local text
>>> segment "t" .
>>>
>>
>> Grr... this may require us to toss out some symbol patterns that are
>> generated
>> by GCC.
>>
>>
>>>
>>> [lunatic@lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe |
>>> grep -i csw
>>> 40010c18 t CSWTCH.1
>>>
>>
>> I see this also on the sparc. On the i386, it is rodata.
>>
>>
>>>
>>> I followed the INFO messages for a mismatch in
>>> _Workspace_Allocate_or_fatal_error
>>>
>>> here's what I came up with
>>>
>>> --- capture.exe
>>> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d
>>> capture/capture.exe | grep "_Workspace_Allocate_or_fatal_error"
>>> 40010c5c: 40 00 15 8c call  4001628c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 400117ac: 40 00 12 b8 call  4001628c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 40011938: 40 00 12 55 call  4001628c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 40015c94: 40 00 01 7e call  4001628c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 4001628c <_Workspace_Allocate_or_fatal_error>:
>>> 400162ac: 02 80 00 04 be  400162bc <_Workspace_Allocate_or_fatal_
>>> error+0x30>
>>> 4002cb14: 7f ff a5 de call  4001628c <_Workspace_Allocate_or_fatal_
>>> error>
>>>
>>> -- base_sp.exe
>>> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d
>>> base_sp/base_sp.exe | grep "_Workspace_Allocate_or_fatal_error"
>>> 40008068: 40 00 11 49 call  4000c58c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 400089f4: 40 00 0e e6 call  4000c58c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 40008b80: 40 00 0e 83 call  4000c58c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 4000c0e0: 40 00 01 2b call  4000c58c <_Workspace_Allocate_or_fatal_
>>> error>
>>> 4000c58c <_Workspace_Allocate_or_fatal_error>:
>>> 4000c5ac: 02 80 00 04 be  4000c5bc <_Workspace_Allocate_or_fatal_
>>> error+0x30>
>>>
>>
>> That shows the references to the symbol not the size. You need to
>> look at the start of
>> the symbol and start of the following symbol.
>>
>> I looked at the "nm -N" output for base_sp.
>>
>> 0200ba0c T _Workspace_Allocate_or_fatal_error
>> 0200ba48 T _SPARC_Counter_read_address
>>
>> I get this for base_sp
> 4000c58c T _Workspace_Allocate_or_fatal_error
> 4000c5e0 T syscall
>
> 0xe0 - 0x8c = 0x54 ==> 84
>
>
>> And for capture:
>>
>> 02015c3c T _Workspace_Allocate_or_fatal_error
>> 02015c78 T rtems_shell_wait_for_explicit_input
>>
>>  4001628c T _Workspace_Allocate_or_fatal_error
> 400162c8 T rtems_shell_wait_for_explicit_input
>
> 0xc8 - 0x8c = 0x3C ==> 60
>

 OK. In base_sp.exe, what is at the end of the method
 _Workspace_Allocate_or_fatal_error before the beginning of syscall?


>>>  _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
>>> 4000c5bc:   7f ff eb 70 call  4000737c <_Internal_error>
>>> 4000c5c0:   90 10 20 03 mov  3, %o0
>>> 4000c5c4:   01 00 00 00 nop
>>>
>>> When you compare the code for  _Workspace_Allocate_or_fatal_error in
 both .exe files, are they the same? They should be since the code is coming
 from a library and it always has matched in the past. But...


>>> it looks the same though.
>>>
>>
>> Are you sure those are the two executables which it is tripping over?
>>
> they 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 22 May 2018 at 00:33, Joel Sherrill  wrote:

>
>
> On Mon, May 21, 2018, 1:54 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 23:07, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, May 21, 2018, 12:01 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 21 May 2018 at 21:42, Joel Sherrill  wrote:

>
>
> On Mon, May 21, 2018 at 10:13 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 20:37, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 21 May 2018 at 17:39, Joel Sherrill  wrote:

> CPU-rtems5-objdump
>
> sparc-rtems5-objdump worked  , thanks .
 I can see some mismatches in the disassembly .

>>>
>>> I'm building sparc now. What mismatches do you see?
>>>
>>> I started another thread for CSWTCH.*. That's not the type of
>>> mismatch Cillian
>>> worked on last summer. It is a symbol that isn't even code and
>>> shouldn't be
>>> in the symbol set.
>>>
>>>
>> I saw the other thread . In sparc I'm getting CSWTCH.* in local text
>> segment "t" .
>>
>
> Grr... this may require us to toss out some symbol patterns that are
> generated
> by GCC.
>
>
>>
>> [lunatic@lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe |
>> grep -i csw
>> 40010c18 t CSWTCH.1
>>
>
> I see this also on the sparc. On the i386, it is rodata.
>
>
>>
>> I followed the INFO messages for a mismatch in
>> _Workspace_Allocate_or_fatal_error
>>
>> here's what I came up with
>>
>> --- capture.exe
>> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d
>> capture/capture.exe | grep "_Workspace_Allocate_or_fatal_error"
>> 40010c5c: 40 00 15 8c call  4001628c <_Workspace_Allocate_or_fatal_
>> error>
>> 400117ac: 40 00 12 b8 call  4001628c <_Workspace_Allocate_or_fatal_
>> error>
>> 40011938: 40 00 12 55 call  4001628c <_Workspace_Allocate_or_fatal_
>> error>
>> 40015c94: 40 00 01 7e call  4001628c <_Workspace_Allocate_or_fatal_
>> error>
>> 4001628c <_Workspace_Allocate_or_fatal_error>:
>> 400162ac: 02 80 00 04 be  400162bc <_Workspace_Allocate_or_fatal_
>> error+0x30>
>> 4002cb14: 7f ff a5 de call  4001628c <_Workspace_Allocate_or_fatal_
>> error>
>>
>> -- base_sp.exe
>> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d
>> base_sp/base_sp.exe | grep "_Workspace_Allocate_or_fatal_error"
>> 40008068: 40 00 11 49 call  4000c58c <_Workspace_Allocate_or_fatal_
>> error>
>> 400089f4: 40 00 0e e6 call  4000c58c <_Workspace_Allocate_or_fatal_
>> error>
>> 40008b80: 40 00 0e 83 call  4000c58c <_Workspace_Allocate_or_fatal_
>> error>
>> 4000c0e0: 40 00 01 2b call  4000c58c <_Workspace_Allocate_or_fatal_
>> error>
>> 4000c58c <_Workspace_Allocate_or_fatal_error>:
>> 4000c5ac: 02 80 00 04 be  4000c5bc <_Workspace_Allocate_or_fatal_
>> error+0x30>
>>
>
> That shows the references to the symbol not the size. You need to look
> at the start of
> the symbol and start of the following symbol.
>
> I looked at the "nm -N" output for base_sp.
>
> 0200ba0c T _Workspace_Allocate_or_fatal_error
> 0200ba48 T _SPARC_Counter_read_address
>
> I get this for base_sp
 4000c58c T _Workspace_Allocate_or_fatal_error
 4000c5e0 T syscall

 0xe0 - 0x8c = 0x54 ==> 84


> And for capture:
>
> 02015c3c T _Workspace_Allocate_or_fatal_error
> 02015c78 T rtems_shell_wait_for_explicit_input
>
>  4001628c T _Workspace_Allocate_or_fatal_error
 400162c8 T rtems_shell_wait_for_explicit_input

 0xc8 - 0x8c = 0x3C ==> 60

>>>
>>> OK. In base_sp.exe, what is at the end of the method
>>> _Workspace_Allocate_or_fatal_error before the beginning of syscall?
>>>
>>>
>>  _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
>> 4000c5bc:   7f ff eb 70 call  4000737c <_Internal_error>
>> 4000c5c0:   90 10 20 03 mov  3, %o0
>> 4000c5c4:   01 00 00 00 nop
>>
>> When you compare the code for  _Workspace_Allocate_or_fatal_error in
>>> both .exe files, are they the same? They should be since the code is coming
>>> from a library and it always has matched in the past. But...
>>>
>>>
>> it looks the same though.
>>
>
> Are you sure those are the two executables which it is tripping over?
>
they were the first two in the list . seems like there are other exes
having conflict with base_sp in other symbols.

have a look
=
INFO: DesiredSymbols::createCoverageMap - Attempt to create unified

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

On Mon, May 21, 2018, 1:54 PM Vijay Kumar Banerjee 
wrote:

> On 21 May 2018 at 23:07, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 21, 2018, 12:01 PM Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 21:42, Joel Sherrill  wrote:
>>>


 On Mon, May 21, 2018 at 10:13 AM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 20:37, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 17:39, Joel Sherrill  wrote:
>>>
 CPU-rtems5-objdump

 sparc-rtems5-objdump worked  , thanks .
>>> I can see some mismatches in the disassembly .
>>>
>>
>> I'm building sparc now. What mismatches do you see?
>>
>> I started another thread for CSWTCH.*. That's not the type of
>> mismatch Cillian
>> worked on last summer. It is a symbol that isn't even code and
>> shouldn't be
>> in the symbol set.
>>
>>
> I saw the other thread . In sparc I'm getting CSWTCH.* in local text
> segment "t" .
>

 Grr... this may require us to toss out some symbol patterns that are
 generated
 by GCC.


>
> [lunatic@lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe | grep
> -i csw
> 40010c18 t CSWTCH.1
>

 I see this also on the sparc. On the i386, it is rodata.


>
> I followed the INFO messages for a mismatch in
> _Workspace_Allocate_or_fatal_error
>
> here's what I came up with
>
> --- capture.exe
> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d
> capture/capture.exe | grep "_Workspace_Allocate_or_fatal_error"
> 40010c5c: 40 00 15 8c call  4001628c
> <_Workspace_Allocate_or_fatal_error>
> 400117ac: 40 00 12 b8 call  4001628c
> <_Workspace_Allocate_or_fatal_error>
> 40011938: 40 00 12 55 call  4001628c
> <_Workspace_Allocate_or_fatal_error>
> 40015c94: 40 00 01 7e call  4001628c
> <_Workspace_Allocate_or_fatal_error>
> 4001628c <_Workspace_Allocate_or_fatal_error>:
> 400162ac: 02 80 00 04 be  400162bc
> <_Workspace_Allocate_or_fatal_error+0x30>
> 4002cb14: 7f ff a5 de call  4001628c
> <_Workspace_Allocate_or_fatal_error>
>
> -- base_sp.exe
> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d
> base_sp/base_sp.exe | grep "_Workspace_Allocate_or_fatal_error"
> 40008068: 40 00 11 49 call  4000c58c
> <_Workspace_Allocate_or_fatal_error>
> 400089f4: 40 00 0e e6 call  4000c58c
> <_Workspace_Allocate_or_fatal_error>
> 40008b80: 40 00 0e 83 call  4000c58c
> <_Workspace_Allocate_or_fatal_error>
> 4000c0e0: 40 00 01 2b call  4000c58c
> <_Workspace_Allocate_or_fatal_error>
> 4000c58c <_Workspace_Allocate_or_fatal_error>:
> 4000c5ac: 02 80 00 04 be  4000c5bc
> <_Workspace_Allocate_or_fatal_error+0x30>
>

 That shows the references to the symbol not the size. You need to look
 at the start of
 the symbol and start of the following symbol.

 I looked at the "nm -N" output for base_sp.

 0200ba0c T _Workspace_Allocate_or_fatal_error
 0200ba48 T _SPARC_Counter_read_address

 I get this for base_sp
>>> 4000c58c T _Workspace_Allocate_or_fatal_error
>>> 4000c5e0 T syscall
>>>
>>> 0xe0 - 0x8c = 0x54 ==> 84
>>>
>>>
 And for capture:

 02015c3c T _Workspace_Allocate_or_fatal_error
 02015c78 T rtems_shell_wait_for_explicit_input

  4001628c T _Workspace_Allocate_or_fatal_error
>>> 400162c8 T rtems_shell_wait_for_explicit_input
>>>
>>> 0xc8 - 0x8c = 0x3C ==> 60
>>>
>>
>> OK. In base_sp.exe, what is at the end of the method
>> _Workspace_Allocate_or_fatal_error before the beginning of syscall?
>>
>>
>  _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
> 4000c5bc:   7f ff eb 70 call  4000737c <_Internal_error>
> 4000c5c0:   90 10 20 03 mov  3, %o0
> 4000c5c4:   01 00 00 00 nop
>
> When you compare the code for  _Workspace_Allocate_or_fatal_error in both
>> .exe files, are they the same? They should be since the code is coming from
>> a library and it always has matched in the past. But...
>>
>>
> it looks the same though.
>

Are you sure those are the two executables which it is tripping over?

I have never seen a case where the code matched by hand and covoar messed
up. But there is always the first. :)

Are you running with just those two executables?

If the input Is the same and covoar doesn't believe it, then gdb is your
friend. Or you will have to add some helpful verbose messages that Cillian
and I couldn't.



>>> base_sp: 0x48 - 0x0c = 0x3C ==> 60
 capture: 0x78 - 0x3c = 0x3c ==> 60

 Based on that alone, they are the same size. Now let's 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 21 May 2018 at 23:07, Joel Sherrill  wrote:

>
>
> On Mon, May 21, 2018, 12:01 PM Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 21:42, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, May 21, 2018 at 10:13 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 21 May 2018 at 20:37, Joel Sherrill  wrote:

>
>
> On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 17:39, Joel Sherrill  wrote:
>>
>>> CPU-rtems5-objdump
>>>
>>> sparc-rtems5-objdump worked  , thanks .
>> I can see some mismatches in the disassembly .
>>
>
> I'm building sparc now. What mismatches do you see?
>
> I started another thread for CSWTCH.*. That's not the type of mismatch
> Cillian
> worked on last summer. It is a symbol that isn't even code and
> shouldn't be
> in the symbol set.
>
>
 I saw the other thread . In sparc I'm getting CSWTCH.* in local text
 segment "t" .

>>>
>>> Grr... this may require us to toss out some symbol patterns that are
>>> generated
>>> by GCC.
>>>
>>>

 [lunatic@lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe | grep
 -i csw
 40010c18 t CSWTCH.1

>>>
>>> I see this also on the sparc. On the i386, it is rodata.
>>>
>>>

 I followed the INFO messages for a mismatch in
 _Workspace_Allocate_or_fatal_error

 here's what I came up with

 --- capture.exe
 [lunatic@lunatic samples]$ sparc-rtems5-objdump -d capture/capture.exe
 | grep "_Workspace_Allocate_or_fatal_error"
 40010c5c: 40 00 15 8c call  4001628c <_Workspace_Allocate_or_fatal_
 error>
 400117ac: 40 00 12 b8 call  4001628c <_Workspace_Allocate_or_fatal_
 error>
 40011938: 40 00 12 55 call  4001628c <_Workspace_Allocate_or_fatal_
 error>
 40015c94: 40 00 01 7e call  4001628c <_Workspace_Allocate_or_fatal_
 error>
 4001628c <_Workspace_Allocate_or_fatal_error>:
 400162ac: 02 80 00 04 be  400162bc <_Workspace_Allocate_or_fatal_
 error+0x30>
 4002cb14: 7f ff a5 de call  4001628c <_Workspace_Allocate_or_fatal_
 error>

 -- base_sp.exe
 [lunatic@lunatic samples]$ sparc-rtems5-objdump -d base_sp/base_sp.exe
 | grep "_Workspace_Allocate_or_fatal_error"
 40008068: 40 00 11 49 call  4000c58c <_Workspace_Allocate_or_fatal_
 error>
 400089f4: 40 00 0e e6 call  4000c58c <_Workspace_Allocate_or_fatal_
 error>
 40008b80: 40 00 0e 83 call  4000c58c <_Workspace_Allocate_or_fatal_
 error>
 4000c0e0: 40 00 01 2b call  4000c58c <_Workspace_Allocate_or_fatal_
 error>
 4000c58c <_Workspace_Allocate_or_fatal_error>:
 4000c5ac: 02 80 00 04 be  4000c5bc <_Workspace_Allocate_or_fatal_
 error+0x30>

>>>
>>> That shows the references to the symbol not the size. You need to look
>>> at the start of
>>> the symbol and start of the following symbol.
>>>
>>> I looked at the "nm -N" output for base_sp.
>>>
>>> 0200ba0c T _Workspace_Allocate_or_fatal_error
>>> 0200ba48 T _SPARC_Counter_read_address
>>>
>>> I get this for base_sp
>> 4000c58c T _Workspace_Allocate_or_fatal_error
>> 4000c5e0 T syscall
>>
>> 0xe0 - 0x8c = 0x54 ==> 84
>>
>>
>>> And for capture:
>>>
>>> 02015c3c T _Workspace_Allocate_or_fatal_error
>>> 02015c78 T rtems_shell_wait_for_explicit_input
>>>
>>>  4001628c T _Workspace_Allocate_or_fatal_error
>> 400162c8 T rtems_shell_wait_for_explicit_input
>>
>> 0xc8 - 0x8c = 0x3C ==> 60
>>
>
> OK. In base_sp.exe, what is at the end of the method
> _Workspace_Allocate_or_fatal_error before the beginning of syscall?
>
>
 _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
4000c5bc:   7f ff eb 70 call  4000737c <_Internal_error>
4000c5c0:   90 10 20 03 mov  3, %o0
4000c5c4:   01 00 00 00 nop

When you compare the code for  _Workspace_Allocate_or_fatal_error in both
> .exe files, are they the same? They should be since the code is coming from
> a library and it always has matched in the past. But...
>
>
it looks the same though.

>
>> base_sp: 0x48 - 0x0c = 0x3C ==> 60
>>> capture: 0x78 - 0x3c = 0x3c ==> 60
>>>
>>> Based on that alone, they are the same size. Now let's look at the
>>> objdump and see what's
>>> at the end that might look like padding:
>>>
>>> base_sp.exe 
>>> _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
>>>  200ba3c:   7f ff ea d4 call  200658c <_Internal_error>
>>>  200ba40:   90 10 20 03 mov  3, %o0
>>>  200ba44:   01 00 00 00 nop
>>> 
>>>
>>> The nop would be considered padding by covoar since it is at the end of
>>> the method.
>>>
>>> capture.exe ===
>>>
>>> _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
>>>  2015c6c:   7f 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 21 May 2018 at 21:42, Joel Sherrill  wrote:

>
>
> On Mon, May 21, 2018 at 10:13 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 20:37, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 21 May 2018 at 17:39, Joel Sherrill  wrote:

> CPU-rtems5-objdump
>
> sparc-rtems5-objdump worked  , thanks .
 I can see some mismatches in the disassembly .

>>>
>>> I'm building sparc now. What mismatches do you see?
>>>
>>> I started another thread for CSWTCH.*. That's not the type of mismatch
>>> Cillian
>>> worked on last summer. It is a symbol that isn't even code and shouldn't
>>> be
>>> in the symbol set.
>>>
>>>
>> I saw the other thread . In sparc I'm getting CSWTCH.* in local text
>> segment "t" .
>>
>
> Grr... this may require us to toss out some symbol patterns that are
> generated
> by GCC.
>
>
>>
>> [lunatic@lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe | grep -i
>> csw
>> 40010c18 t CSWTCH.1
>>
>
> I see this also on the sparc. On the i386, it is rodata.
>
>
>>
>> I followed the INFO messages for a mismatch in
>> _Workspace_Allocate_or_fatal_error
>>
>> here's what I came up with
>>
>> --- capture.exe
>> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d capture/capture.exe |
>> grep "_Workspace_Allocate_or_fatal_error"
>> 40010c5c: 40 00 15 8c call  4001628c <_Workspace_Allocate_or_fatal_error>
>> 400117ac: 40 00 12 b8 call  4001628c <_Workspace_Allocate_or_fatal_error>
>> 40011938: 40 00 12 55 call  4001628c <_Workspace_Allocate_or_fatal_error>
>> 40015c94: 40 00 01 7e call  4001628c <_Workspace_Allocate_or_fatal_error>
>> 4001628c <_Workspace_Allocate_or_fatal_error>:
>> 400162ac: 02 80 00 04 be  400162bc <_Workspace_Allocate_or_fatal_
>> error+0x30>
>> 4002cb14: 7f ff a5 de call  4001628c <_Workspace_Allocate_or_fatal_error>
>>
>> -- base_sp.exe
>> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d base_sp/base_sp.exe |
>> grep "_Workspace_Allocate_or_fatal_error"
>> 40008068: 40 00 11 49 call  4000c58c <_Workspace_Allocate_or_fatal_error>
>> 400089f4: 40 00 0e e6 call  4000c58c <_Workspace_Allocate_or_fatal_error>
>> 40008b80: 40 00 0e 83 call  4000c58c <_Workspace_Allocate_or_fatal_error>
>> 4000c0e0: 40 00 01 2b call  4000c58c <_Workspace_Allocate_or_fatal_error>
>> 4000c58c <_Workspace_Allocate_or_fatal_error>:
>> 4000c5ac: 02 80 00 04 be  4000c5bc <_Workspace_Allocate_or_fatal_
>> error+0x30>
>>
>
> That shows the references to the symbol not the size. You need to look at
> the start of
> the symbol and start of the following symbol.
>
> I looked at the "nm -N" output for base_sp.
>
> 0200ba0c T _Workspace_Allocate_or_fatal_error
> 0200ba48 T _SPARC_Counter_read_address
>
> I get this for base_sp
4000c58c T _Workspace_Allocate_or_fatal_error
4000c5e0 T syscall

0xe0 - 0x8c = 0x54 ==> 84


> And for capture:
>
> 02015c3c T _Workspace_Allocate_or_fatal_error
> 02015c78 T rtems_shell_wait_for_explicit_input
>
>  4001628c T _Workspace_Allocate_or_fatal_error
400162c8 T rtems_shell_wait_for_explicit_input

0xc8 - 0x8c = 0x3C ==> 60

base_sp: 0x48 - 0x0c = 0x3C ==> 60
> capture: 0x78 - 0x3c = 0x3c ==> 60
>
> Based on that alone, they are the same size. Now let's look at the objdump
> and see what's
> at the end that might look like padding:
>
> base_sp.exe 
> _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
>  200ba3c:   7f ff ea d4 call  200658c <_Internal_error>
>  200ba40:   90 10 20 03 mov  3, %o0
>  200ba44:   01 00 00 00 nop
> 
>
> The nop would be considered padding by covoar since it is at the end of
> the method.
>
> capture.exe ===
>
> _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
>  2015c6c:   7f ff e6 53 call  200f5b8 <_Internal_error>
>  2015c70:   90 10 20 03 mov  3, %o0
>  2015c74:   01 00 00 00 nop
>
> 
>
> Comparing the body of the two methods based on objdump output, I don't
> see any difference for sparc/erc32 at -O2.
>
> I repeated looking at the objdump output at -Os and they were the same
> instructions
> and length.
>
> You will have to investigate to see why they are different on your side.
>
> What am I doing different ? Is it because of the covoar patches ?
(have you applied the patches ?)

> --joel
>
>
>
>
>
>>
>>
 Probably i386. Aren't you running pc386?
>
> I'm running sparc


> Not sparc/erc32 or Leon
>
> On Mon, May 21, 2018, 6:35 AM Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 16:39, Cillian O'Donnell 
>>> wrote:
>>>

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

On Mon, May 21, 2018 at 10:13 AM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 20:37, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 17:39, Joel Sherrill  wrote:
>>>
 CPU-rtems5-objdump

 sparc-rtems5-objdump worked  , thanks .
>>> I can see some mismatches in the disassembly .
>>>
>>
>> I'm building sparc now. What mismatches do you see?
>>
>> I started another thread for CSWTCH.*. That's not the type of mismatch
>> Cillian
>> worked on last summer. It is a symbol that isn't even code and shouldn't
>> be
>> in the symbol set.
>>
>>
> I saw the other thread . In sparc I'm getting CSWTCH.* in local text
> segment "t" .
>

Grr... this may require us to toss out some symbol patterns that are
generated
by GCC.


>
> [lunatic@lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe | grep -i
> csw
> 40010c18 t CSWTCH.1
>

I see this also on the sparc. On the i386, it is rodata.


>
> I followed the INFO messages for a mismatch in
> _Workspace_Allocate_or_fatal_error
>
> here's what I came up with
>
> --- capture.exe
> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d capture/capture.exe |
> grep "_Workspace_Allocate_or_fatal_error"
> 40010c5c: 40 00 15 8c call  4001628c <_Workspace_Allocate_or_fatal_error>
> 400117ac: 40 00 12 b8 call  4001628c <_Workspace_Allocate_or_fatal_error>
> 40011938: 40 00 12 55 call  4001628c <_Workspace_Allocate_or_fatal_error>
> 40015c94: 40 00 01 7e call  4001628c <_Workspace_Allocate_or_fatal_error>
> 4001628c <_Workspace_Allocate_or_fatal_error>:
> 400162ac: 02 80 00 04 be  400162bc <_Workspace_Allocate_or_fatal_
> error+0x30>
> 4002cb14: 7f ff a5 de call  4001628c <_Workspace_Allocate_or_fatal_error>
>
> -- base_sp.exe
> [lunatic@lunatic samples]$ sparc-rtems5-objdump -d base_sp/base_sp.exe |
> grep "_Workspace_Allocate_or_fatal_error"
> 40008068: 40 00 11 49 call  4000c58c <_Workspace_Allocate_or_fatal_error>
> 400089f4: 40 00 0e e6 call  4000c58c <_Workspace_Allocate_or_fatal_error>
> 40008b80: 40 00 0e 83 call  4000c58c <_Workspace_Allocate_or_fatal_error>
> 4000c0e0: 40 00 01 2b call  4000c58c <_Workspace_Allocate_or_fatal_error>
> 4000c58c <_Workspace_Allocate_or_fatal_error>:
> 4000c5ac: 02 80 00 04 be  4000c5bc <_Workspace_Allocate_or_fatal_
> error+0x30>
>

That shows the references to the symbol not the size. You need to look at
the start of
the symbol and start of the following symbol.

I looked at the "nm -N" output for base_sp.

0200ba0c T _Workspace_Allocate_or_fatal_error
0200ba48 T _SPARC_Counter_read_address

And for capture:

02015c3c T _Workspace_Allocate_or_fatal_error
02015c78 T rtems_shell_wait_for_explicit_input

base_sp: 0x48 - 0x0c = 0x3C ==> 60
capture: 0x78 - 0x3c = 0x3c ==> 60

Based on that alone, they are the same size. Now let's look at the objdump
and see what's
at the end that might look like padding:

base_sp.exe 
_Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
 200ba3c:   7f ff ea d4 call  200658c <_Internal_error>
 200ba40:   90 10 20 03 mov  3, %o0
 200ba44:   01 00 00 00 nop


The nop would be considered padding by covoar since it is at the end of the
method.

capture.exe ===

_Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
 2015c6c:   7f ff e6 53 call  200f5b8 <_Internal_error>
 2015c70:   90 10 20 03 mov  3, %o0
 2015c74:   01 00 00 00 nop



Comparing the body of the two methods based on objdump output, I don't
see any difference for sparc/erc32 at -O2.

I repeated looking at the objdump output at -Os and they were the same
instructions
and length.

You will have to investigate to see why they are different on your side.

--joel





>
>
>>> Probably i386. Aren't you running pc386?

 I'm running sparc
>>>
>>>
 Not sparc/erc32 or Leon

 On Mon, May 21, 2018, 6:35 AM Cillian O'Donnell 
 wrote:

>
>
> On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 16:39, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, 
>>> wrote:
>>>


 On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 11:56, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 02:29, Cillian O'Donnell <
>>> cpodonne...@gmail.com> wrote:
>>>

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 21 May 2018 at 20:37, Joel Sherrill  wrote:

>
>
> On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 17:39, Joel Sherrill  wrote:
>>
>>> CPU-rtems5-objdump
>>>
>>> sparc-rtems5-objdump worked  , thanks .
>> I can see some mismatches in the disassembly .
>>
>
> I'm building sparc now. What mismatches do you see?
>
> I started another thread for CSWTCH.*. That's not the type of mismatch
> Cillian
> worked on last summer. It is a symbol that isn't even code and shouldn't be
> in the symbol set.
>
>
I saw the other thread . In sparc I'm getting CSWTCH.* in local text
segment "t" .

[lunatic@lunatic samples]$ sparc-rtems5-nm base_sp/base_sp.exe | grep -i csw
40010c18 t CSWTCH.1

I followed the INFO messages for a mismatch in
_Workspace_Allocate_or_fatal_error

here's what I came up with

--- capture.exe
[lunatic@lunatic samples]$ sparc-rtems5-objdump -d capture/capture.exe |
grep "_Workspace_Allocate_or_fatal_error"
40010c5c: 40 00 15 8c call  4001628c <_Workspace_Allocate_or_fatal_error>
400117ac: 40 00 12 b8 call  4001628c <_Workspace_Allocate_or_fatal_error>
40011938: 40 00 12 55 call  4001628c <_Workspace_Allocate_or_fatal_error>
40015c94: 40 00 01 7e call  4001628c <_Workspace_Allocate_or_fatal_error>
4001628c <_Workspace_Allocate_or_fatal_error>:
400162ac: 02 80 00 04 be  400162bc <_Workspace_Allocate_or_fatal_error+0x30>
4002cb14: 7f ff a5 de call  4001628c <_Workspace_Allocate_or_fatal_error>

-- base_sp.exe
[lunatic@lunatic samples]$ sparc-rtems5-objdump -d base_sp/base_sp.exe |
grep "_Workspace_Allocate_or_fatal_error"
40008068: 40 00 11 49 call  4000c58c <_Workspace_Allocate_or_fatal_error>
400089f4: 40 00 0e e6 call  4000c58c <_Workspace_Allocate_or_fatal_error>
40008b80: 40 00 0e 83 call  4000c58c <_Workspace_Allocate_or_fatal_error>
4000c0e0: 40 00 01 2b call  4000c58c <_Workspace_Allocate_or_fatal_error>
4000c58c <_Workspace_Allocate_or_fatal_error>:
4000c5ac: 02 80 00 04 be  4000c5bc <_Workspace_Allocate_or_fatal_error+0x30>


>> Probably i386. Aren't you running pc386?
>>>
>>> I'm running sparc
>>
>>
>>> Not sparc/erc32 or Leon
>>>
>>> On Mon, May 21, 2018, 6:35 AM Cillian O'Donnell 
>>> wrote:
>>>


 On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 16:39, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, 
>> wrote:
>>
>>>
>>>
>>> On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 21 May 2018 at 11:56, Cillian O'Donnell 
 wrote:

>
>
> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 02:29, Cillian O'Donnell > > wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

>
>
> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, <
> cpodonne...@gmail.com> wrote:
>
>> It works.. Sorry I was using the right covoar but the wrong
>> rtems-test. Ahh its nice to see the data back in the reports 
>> again. Did you
>> manage to track down 2 exes with the mismatch in symbol size?
>>
> Great! so next is the parsing of the symbol file.
> I couldn't manage to track down the mismatch.
>
> I have pushed these to my master branch.

 The latest update to cov-tester-support branch (please have a
 look)
 parses the symbol-set ini file from the coverage script. The
 parsing
 is working but currently it's not generating reports, as covoar
 needs to be updated .

>>>
>>> It's best if covoar reads it's own config file, otherwise it
>>> creates a dependency on the tester. Scanning over the recent 
>>> changes to
>>> covoar there, it looks like it can already handle multiple sets, so 
>>> the one
>>> ini with multiple sets in it is the way to go.
>>>
>> Okay, Understood.
>>
>>> Here are the things that I have done and that needs to be
 done in order to generate reports :

 I have added a symbol-sets.ini file and parsed it from the
 coverage script
 this is how it works :


- The ini 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

On Mon, May 21, 2018 at 9:52 AM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 17:39, Joel Sherrill  wrote:
>
>> CPU-rtems5-objdump
>>
>> sparc-rtems5-objdump worked  , thanks .
> I can see some mismatches in the disassembly .
>

I'm building sparc now. What mismatches do you see?

I started another thread for CSWTCH.*. That's not the type of mismatch
Cillian
worked on last summer. It is a symbol that isn't even code and shouldn't be
in the symbol set.


>
> Probably i386. Aren't you running pc386?
>>
>> I'm running sparc
>
>
>> Not sparc/erc32 or Leon
>>
>> On Mon, May 21, 2018, 6:35 AM Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 21 May 2018 at 16:39, Cillian O'Donnell 
 wrote:

>
>
> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, 
> wrote:
>
>>
>>
>> On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 11:56, Cillian O'Donnell 
>>> wrote:
>>>


 On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 02:29, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>


 On Sun, 20 May 2018, 00:45 Cillian O'Donnell, <
 cpodonne...@gmail.com> wrote:

> It works.. Sorry I was using the right covoar but the wrong
> rtems-test. Ahh its nice to see the data back in the reports 
> again. Did you
> manage to track down 2 exes with the mismatch in symbol size?
>
 Great! so next is the parsing of the symbol file.
 I couldn't manage to track down the mismatch.

 I have pushed these to my master branch.
>>>
>>> The latest update to cov-tester-support branch (please have a
>>> look)
>>> parses the symbol-set ini file from the coverage script. The
>>> parsing
>>> is working but currently it's not generating reports, as covoar
>>> needs to be updated .
>>>
>>
>> It's best if covoar reads it's own config file, otherwise it
>> creates a dependency on the tester. Scanning over the recent changes 
>> to
>> covoar there, it looks like it can already handle multiple sets, so 
>> the one
>> ini with multiple sets in it is the way to go.
>>
> Okay, Understood.
>
>> Here are the things that I have done and that needs to be
>>> done in order to generate reports :
>>>
>>> I have added a symbol-sets.ini file and parsed it from the
>>> coverage script
>>> this is how it works :
>>>
>>>
>>>- The ini file can be updated with all the symbols,
>>>separated by ' , ' (comma)
>>>
>>>
>> This is the way covoar is actually handling it now. You should
>> test a multi set ini and see if that's working.
>>
> Yeah, I have seen it. will try with multiple sets.
>
>>
>>>-
>>>- The coverages splits them and makes a list of all the sets
>>>-  The respective libraries are parsed from the libraries
>>>section.
>>>- It returns a dict with all the symbols and thir resp.
>>>library addresses.
>>>- The library addresses are absolute so it can be run from
>>>anywhere
>>>top of build tree is not necessary.
>>>
>>> This was a good idea but it's just that dependency issue we want
>> to stay away from. Covoar has something to find the build directory 
>> too, it
>> just hasn't been connected up yet, so running it from the top of the 
>> build
>> directory is ok for the moment.
>>
>
> yes it can find the build directory. I was giving it a shot to do
> it from the script.
>
> If covoar's standalone working is a necessity then it surely needs
> to be working
> from covoar and shouldn't depend on the script.
>

 It should be working from covoar and it will.

>
>> Probably the most pressing thing now is investigating those
>> mismatch in symbol size.
>>
>
> any advice on where/how to look for it ?

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 21 May 2018 at 17:39, Joel Sherrill  wrote:

> CPU-rtems5-objdump
>
> sparc-rtems5-objdump worked  , thanks .
I can see some mismatches in the disassembly .

Probably i386. Aren't you running pc386?
>
> I'm running sparc


> Not sparc/erc32 or Leon
>
> On Mon, May 21, 2018, 6:35 AM Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 16:39, Cillian O'Donnell 
>>> wrote:
>>>


 On Mon, 21 May 2018, 12:08 Cillian O'Donnell, 
 wrote:

>
>
> On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 11:56, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 21 May 2018 at 02:29, Cillian O'Donnell 
 wrote:

>
>
> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, <
>>> cpodonne...@gmail.com> wrote:
>>>
 It works.. Sorry I was using the right covoar but the wrong
 rtems-test. Ahh its nice to see the data back in the reports 
 again. Did you
 manage to track down 2 exes with the mismatch in symbol size?

>>> Great! so next is the parsing of the symbol file.
>>> I couldn't manage to track down the mismatch.
>>>
>>> I have pushed these to my master branch.
>>
>> The latest update to cov-tester-support branch (please have a
>> look)
>> parses the symbol-set ini file from the coverage script. The
>> parsing
>> is working but currently it's not generating reports, as covoar
>> needs to be updated .
>>
>
> It's best if covoar reads it's own config file, otherwise it
> creates a dependency on the tester. Scanning over the recent changes 
> to
> covoar there, it looks like it can already handle multiple sets, so 
> the one
> ini with multiple sets in it is the way to go.
>
 Okay, Understood.

> Here are the things that I have done and that needs to be
>> done in order to generate reports :
>>
>> I have added a symbol-sets.ini file and parsed it from the
>> coverage script
>> this is how it works :
>>
>>
>>- The ini file can be updated with all the symbols, separated
>>by ' , ' (comma)
>>
>>
> This is the way covoar is actually handling it now. You should
> test a multi set ini and see if that's working.
>
 Yeah, I have seen it. will try with multiple sets.

>
>>-
>>- The coverages splits them and makes a list of all the sets
>>-  The respective libraries are parsed from the libraries
>>section.
>>- It returns a dict with all the symbols and thir resp.
>>library addresses.
>>- The library addresses are absolute so it can be run from
>>anywhere
>>top of build tree is not necessary.
>>
>> This was a good idea but it's just that dependency issue we want
> to stay away from. Covoar has something to find the build directory 
> too, it
> just hasn't been connected up yet, so running it from the top of the 
> build
> directory is ok for the moment.
>

 yes it can find the build directory. I was giving it a shot to do
 it from the script.

 If covoar's standalone working is a necessity then it surely needs
 to be working
 from covoar and shouldn't depend on the script.

>>>
>>> It should be working from covoar and it will.
>>>

> Probably the most pressing thing now is investigating those
> mismatch in symbol size.
>

 any advice on where/how to look for it ?

>>>
>>> Before what I was doing was examining the objdump of 2 exes, looking
>>> there on the weekend i think the info messages mentioned which ones were
>>> having trouble for which symbol. It says something like "couldn't merge
>>> coverage map for some_symbol because sizes from exe != to size of
>>> other_exe. Look at the objdump of exe and other_exe, search for 
>>> some_symbol
>>> and compare the dissasembly. There'll 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

CPU-rtems5-objdump

Probably i386. Aren't you running pc386?

Not sparc/erc32 or Leon

On Mon, May 21, 2018, 6:35 AM Cillian O'Donnell 
wrote:

>
>
> On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, 
> wrote:
>
>> On 21 May 2018 at 16:39, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, 
>>> wrote:
>>>


 On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 11:56, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 02:29, Cillian O'Donnell 
>>> wrote:
>>>


 On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, <
>> cpodonne...@gmail.com> wrote:
>>
>>> It works.. Sorry I was using the right covoar but the wrong
>>> rtems-test. Ahh its nice to see the data back in the reports again. 
>>> Did you
>>> manage to track down 2 exes with the mismatch in symbol size?
>>>
>> Great! so next is the parsing of the symbol file.
>> I couldn't manage to track down the mismatch.
>>
>> I have pushed these to my master branch.
>
> The latest update to cov-tester-support branch (please have a look)
> parses the symbol-set ini file from the coverage script. The
> parsing
> is working but currently it's not generating reports, as covoar
> needs to be updated .
>

 It's best if covoar reads it's own config file, otherwise it
 creates a dependency on the tester. Scanning over the recent changes to
 covoar there, it looks like it can already handle multiple sets, so 
 the one
 ini with multiple sets in it is the way to go.

>>> Okay, Understood.
>>>
 Here are the things that I have done and that needs to be
> done in order to generate reports :
>
> I have added a symbol-sets.ini file and parsed it from the
> coverage script
> this is how it works :
>
>
>- The ini file can be updated with all the symbols, separated
>by ' , ' (comma)
>
>
 This is the way covoar is actually handling it now. You should test
 a multi set ini and see if that's working.

>>> Yeah, I have seen it. will try with multiple sets.
>>>

>-
>- The coverages splits them and makes a list of all the sets
>-  The respective libraries are parsed from the libraries
>section.
>- It returns a dict with all the symbols and thir resp.
>library addresses.
>- The library addresses are absolute so it can be run from
>anywhere
>top of build tree is not necessary.
>
> This was a good idea but it's just that dependency issue we want
 to stay away from. Covoar has something to find the build directory 
 too, it
 just hasn't been connected up yet, so running it from the top of the 
 build
 directory is ok for the moment.

>>>
>>> yes it can find the build directory. I was giving it a shot to do it
>>> from the script.
>>>
>>> If covoar's standalone working is a necessity then it surely needs
>>> to be working
>>> from covoar and shouldn't depend on the script.
>>>
>>
>> It should be working from covoar and it will.
>>
>>>
 Probably the most pressing thing now is investigating those
 mismatch in symbol size.

>>>
>>> any advice on where/how to look for it ?
>>>
>>
>> Before what I was doing was examining the objdump of 2 exes, looking
>> there on the weekend i think the info messages mentioned which ones were
>> having trouble for which symbol. It says something like "couldn't merge
>> coverage map for some_symbol because sizes from exe != to size of
>> other_exe. Look at the objdump of exe and other_exe, search for 
>> some_symbol
>> and compare the dissasembly. There'll be more lines in one than the 
>> other,
>> nop padding probably. Then you had to find a check that was strict enough
>> to chop the end of the symbol in question at the right place but not so
>> strict that it chopped other symbols in the wrong place. However the 
>> method
>> of obtaining the symbols has changed, 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, 
wrote:

> On 21 May 2018 at 16:39, Cillian O'Donnell  wrote:
>
>>
>>
>> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, 
>> wrote:
>>
>>>
>>>
>>> On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 21 May 2018 at 11:56, Cillian O'Donnell 
 wrote:

>
>
> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>> On 21 May 2018 at 02:29, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

>
>
> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, <
> cpodonne...@gmail.com> wrote:
>
>> It works.. Sorry I was using the right covoar but the wrong
>> rtems-test. Ahh its nice to see the data back in the reports again. 
>> Did you
>> manage to track down 2 exes with the mismatch in symbol size?
>>
> Great! so next is the parsing of the symbol file.
> I couldn't manage to track down the mismatch.
>
> I have pushed these to my master branch.

 The latest update to cov-tester-support branch (please have a look)
 parses the symbol-set ini file from the coverage script. The
 parsing
 is working but currently it's not generating reports, as covoar
 needs to be updated .

>>>
>>> It's best if covoar reads it's own config file, otherwise it creates
>>> a dependency on the tester. Scanning over the recent changes to covoar
>>> there, it looks like it can already handle multiple sets, so the one ini
>>> with multiple sets in it is the way to go.
>>>
>> Okay, Understood.
>>
>>> Here are the things that I have done and that needs to be
 done in order to generate reports :

 I have added a symbol-sets.ini file and parsed it from the coverage
 script
 this is how it works :


- The ini file can be updated with all the symbols, separated
by ' , ' (comma)


>>> This is the way covoar is actually handling it now. You should test
>>> a multi set ini and see if that's working.
>>>
>> Yeah, I have seen it. will try with multiple sets.
>>
>>>
-
- The coverages splits them and makes a list of all the sets
-  The respective libraries are parsed from the libraries
section.
- It returns a dict with all the symbols and thir resp. library
addresses.
- The library addresses are absolute so it can be run from
anywhere
top of build tree is not necessary.

 This was a good idea but it's just that dependency issue we want to
>>> stay away from. Covoar has something to find the build directory too, it
>>> just hasn't been connected up yet, so running it from the top of the 
>>> build
>>> directory is ok for the moment.
>>>
>>
>> yes it can find the build directory. I was giving it a shot to do it
>> from the script.
>>
>> If covoar's standalone working is a necessity then it surely needs to
>> be working
>> from covoar and shouldn't depend on the script.
>>
>
> It should be working from covoar and it will.
>
>>
>>> Probably the most pressing thing now is investigating those mismatch
>>> in symbol size.
>>>
>>
>> any advice on where/how to look for it ?
>>
>
> Before what I was doing was examining the objdump of 2 exes, looking
> there on the weekend i think the info messages mentioned which ones were
> having trouble for which symbol. It says something like "couldn't merge
> coverage map for some_symbol because sizes from exe != to size of
> other_exe. Look at the objdump of exe and other_exe, search for 
> some_symbol
> and compare the dissasembly. There'll be more lines in one than the other,
> nop padding probably. Then you had to find a check that was strict enough
> to chop the end of the symbol in question at the right place but not so
> strict that it chopped other symbols in the wrong place. However the 
> method
> of obtaining the symbols has changed, I'll have to have a look over the
> covoar changes tonight to see what would be the equivalent method of
> checking this now. Unless Chris or Joel come back with the answer before
> then.
>
> Please have a look into this as I'm confused .
 From the messages it seems like there's something with
 the 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 21 May 2018 at 16:39, Cillian O'Donnell  wrote:

>
>
> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, 
> wrote:
>
>>
>>
>> On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 11:56, Cillian O'Donnell 
>>> wrote:
>>>


 On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

> On 21 May 2018 at 02:29, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>


 On Sun, 20 May 2018, 00:45 Cillian O'Donnell, <
 cpodonne...@gmail.com> wrote:

> It works.. Sorry I was using the right covoar but the wrong
> rtems-test. Ahh its nice to see the data back in the reports again. 
> Did you
> manage to track down 2 exes with the mismatch in symbol size?
>
 Great! so next is the parsing of the symbol file.
 I couldn't manage to track down the mismatch.

 I have pushed these to my master branch.
>>>
>>> The latest update to cov-tester-support branch (please have a look)
>>> parses the symbol-set ini file from the coverage script. The parsing
>>> is working but currently it's not generating reports, as covoar
>>> needs to be updated .
>>>
>>
>> It's best if covoar reads it's own config file, otherwise it creates
>> a dependency on the tester. Scanning over the recent changes to covoar
>> there, it looks like it can already handle multiple sets, so the one ini
>> with multiple sets in it is the way to go.
>>
> Okay, Understood.
>
>> Here are the things that I have done and that needs to be
>>> done in order to generate reports :
>>>
>>> I have added a symbol-sets.ini file and parsed it from the coverage
>>> script
>>> this is how it works :
>>>
>>>
>>>- The ini file can be updated with all the symbols, separated by
>>>' , ' (comma)
>>>
>>>
>> This is the way covoar is actually handling it now. You should test a
>> multi set ini and see if that's working.
>>
> Yeah, I have seen it. will try with multiple sets.
>
>>
>>>-
>>>- The coverages splits them and makes a list of all the sets
>>>-  The respective libraries are parsed from the libraries
>>>section.
>>>- It returns a dict with all the symbols and thir resp. library
>>>addresses.
>>>- The library addresses are absolute so it can be run from
>>>anywhere
>>>top of build tree is not necessary.
>>>
>>> This was a good idea but it's just that dependency issue we want to
>> stay away from. Covoar has something to find the build directory too, it
>> just hasn't been connected up yet, so running it from the top of the 
>> build
>> directory is ok for the moment.
>>
>
> yes it can find the build directory. I was giving it a shot to do it
> from the script.
>
> If covoar's standalone working is a necessity then it surely needs to
> be working
> from covoar and shouldn't depend on the script.
>

 It should be working from covoar and it will.

>
>> Probably the most pressing thing now is investigating those mismatch
>> in symbol size.
>>
>
> any advice on where/how to look for it ?
>

 Before what I was doing was examining the objdump of 2 exes, looking
 there on the weekend i think the info messages mentioned which ones were
 having trouble for which symbol. It says something like "couldn't merge
 coverage map for some_symbol because sizes from exe != to size of
 other_exe. Look at the objdump of exe and other_exe, search for some_symbol
 and compare the dissasembly. There'll be more lines in one than the other,
 nop padding probably. Then you had to find a check that was strict enough
 to chop the end of the symbol in question at the right place but not so
 strict that it chopped other symbols in the wrong place. However the method
 of obtaining the symbols has changed, I'll have to have a look over the
 covoar changes tonight to see what would be the equivalent method of
 checking this now. Unless Chris or Joel come back with the answer before
 then.

 Please have a look into this as I'm confused .
>>> From the messages it seems like there's something with
>>> the base_sp.exe .
>>> I tried to run objdum with -d , I'm getting an error
>>> objdump: can't disassemble for architecture UNKNOWN!
>>> what am I missing ?
>>>
>>
>> It'll be a sparc-objdump that was built with the rsb in 5/bin/. I'm not
>> 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 21 May 2018, 12:08 Cillian O'Donnell,  wrote:

>
>
> On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, 
> wrote:
>
>> On 21 May 2018 at 11:56, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 21 May 2018 at 02:29, Cillian O'Donnell 
 wrote:

>
>
> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>>> wrote:
>>>
 It works.. Sorry I was using the right covoar but the wrong
 rtems-test. Ahh its nice to see the data back in the reports again. 
 Did you
 manage to track down 2 exes with the mismatch in symbol size?

>>> Great! so next is the parsing of the symbol file.
>>> I couldn't manage to track down the mismatch.
>>>
>>> I have pushed these to my master branch.
>>
>> The latest update to cov-tester-support branch (please have a look)
>> parses the symbol-set ini file from the coverage script. The parsing
>> is working but currently it's not generating reports, as covoar
>> needs to be updated .
>>
>
> It's best if covoar reads it's own config file, otherwise it creates a
> dependency on the tester. Scanning over the recent changes to covoar 
> there,
> it looks like it can already handle multiple sets, so the one ini with
> multiple sets in it is the way to go.
>
 Okay, Understood.

> Here are the things that I have done and that needs to be
>> done in order to generate reports :
>>
>> I have added a symbol-sets.ini file and parsed it from the coverage
>> script
>> this is how it works :
>>
>>
>>- The ini file can be updated with all the symbols, separated by
>>' , ' (comma)
>>
>>
> This is the way covoar is actually handling it now. You should test a
> multi set ini and see if that's working.
>
 Yeah, I have seen it. will try with multiple sets.

>
>>-
>>- The coverages splits them and makes a list of all the sets
>>-  The respective libraries are parsed from the libraries section.
>>- It returns a dict with all the symbols and thir resp. library
>>addresses.
>>- The library addresses are absolute so it can be run from
>>anywhere
>>top of build tree is not necessary.
>>
>> This was a good idea but it's just that dependency issue we want to
> stay away from. Covoar has something to find the build directory too, it
> just hasn't been connected up yet, so running it from the top of the build
> directory is ok for the moment.
>

 yes it can find the build directory. I was giving it a shot to do it
 from the script.

 If covoar's standalone working is a necessity then it surely needs to
 be working
 from covoar and shouldn't depend on the script.

>>>
>>> It should be working from covoar and it will.
>>>

> Probably the most pressing thing now is investigating those mismatch
> in symbol size.
>

 any advice on where/how to look for it ?

>>>
>>> Before what I was doing was examining the objdump of 2 exes, looking
>>> there on the weekend i think the info messages mentioned which ones were
>>> having trouble for which symbol. It says something like "couldn't merge
>>> coverage map for some_symbol because sizes from exe != to size of
>>> other_exe. Look at the objdump of exe and other_exe, search for some_symbol
>>> and compare the dissasembly. There'll be more lines in one than the other,
>>> nop padding probably. Then you had to find a check that was strict enough
>>> to chop the end of the symbol in question at the right place but not so
>>> strict that it chopped other symbols in the wrong place. However the method
>>> of obtaining the symbols has changed, I'll have to have a look over the
>>> covoar changes tonight to see what would be the equivalent method of
>>> checking this now. Unless Chris or Joel come back with the answer before
>>> then.
>>>
>>> Please have a look into this as I'm confused .
>> From the messages it seems like there's something with
>> the base_sp.exe .
>> I tried to run objdum with -d , I'm getting an error
>> objdump: can't disassemble for architecture UNKNOWN!
>> what am I missing ?
>>
>
> It'll be a sparc-objdump that was built with the rsb in 5/bin/. I'm not
> sure if we're still grabbing the objdump using rtems-tools
>
Sorry *rtemstoolkit

> now, so not 100% sure that this still the way to investigate this.
>
>>
>> Also there will probably be multiple ini's with different collections 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, 
wrote:

> On 21 May 2018 at 11:56, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 02:29, Cillian O'Donnell 
>>> wrote:
>>>


 On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>> wrote:
>>
>>> It works.. Sorry I was using the right covoar but the wrong
>>> rtems-test. Ahh its nice to see the data back in the reports again. Did 
>>> you
>>> manage to track down 2 exes with the mismatch in symbol size?
>>>
>> Great! so next is the parsing of the symbol file.
>> I couldn't manage to track down the mismatch.
>>
>> I have pushed these to my master branch.
>
> The latest update to cov-tester-support branch (please have a look)
> parses the symbol-set ini file from the coverage script. The parsing
> is working but currently it's not generating reports, as covoar
> needs to be updated .
>

 It's best if covoar reads it's own config file, otherwise it creates a
 dependency on the tester. Scanning over the recent changes to covoar there,
 it looks like it can already handle multiple sets, so the one ini with
 multiple sets in it is the way to go.

>>> Okay, Understood.
>>>
 Here are the things that I have done and that needs to be
> done in order to generate reports :
>
> I have added a symbol-sets.ini file and parsed it from the coverage
> script
> this is how it works :
>
>
>- The ini file can be updated with all the symbols, separated by '
>, ' (comma)
>
>
 This is the way covoar is actually handling it now. You should test a
 multi set ini and see if that's working.

>>> Yeah, I have seen it. will try with multiple sets.
>>>

>-
>- The coverages splits them and makes a list of all the sets
>-  The respective libraries are parsed from the libraries section.
>- It returns a dict with all the symbols and thir resp. library
>addresses.
>- The library addresses are absolute so it can be run from anywhere
>top of build tree is not necessary.
>
> This was a good idea but it's just that dependency issue we want to
 stay away from. Covoar has something to find the build directory too, it
 just hasn't been connected up yet, so running it from the top of the build
 directory is ok for the moment.

>>>
>>> yes it can find the build directory. I was giving it a shot to do it
>>> from the script.
>>>
>>> If covoar's standalone working is a necessity then it surely needs to be
>>> working
>>> from covoar and shouldn't depend on the script.
>>>
>>
>> It should be working from covoar and it will.
>>
>>>
 Probably the most pressing thing now is investigating those mismatch in
 symbol size.

>>>
>>> any advice on where/how to look for it ?
>>>
>>
>> Before what I was doing was examining the objdump of 2 exes, looking
>> there on the weekend i think the info messages mentioned which ones were
>> having trouble for which symbol. It says something like "couldn't merge
>> coverage map for some_symbol because sizes from exe != to size of
>> other_exe. Look at the objdump of exe and other_exe, search for some_symbol
>> and compare the dissasembly. There'll be more lines in one than the other,
>> nop padding probably. Then you had to find a check that was strict enough
>> to chop the end of the symbol in question at the right place but not so
>> strict that it chopped other symbols in the wrong place. However the method
>> of obtaining the symbols has changed, I'll have to have a look over the
>> covoar changes tonight to see what would be the equivalent method of
>> checking this now. Unless Chris or Joel come back with the answer before
>> then.
>>
>> Please have a look into this as I'm confused .
> From the messages it seems like there's something with
> the base_sp.exe .
> I tried to run objdum with -d , I'm getting an error
> objdump: can't disassemble for architecture UNKNOWN!
> what am I missing ?
>

It'll be a sparc-objdump that was built with the rsb in 5/bin/. I'm not
sure if we're still grabbing the objdump using rtems-tools now, so not 100%
sure that this still the way to investigate this.

>
> Also there will probably be multiple ini's with different collections of
>> sets that the user could run so it would be good to give them some method
>> of choosing which ini they want, like coverage=score will feed score.ini to
>> covoar. You could try have a go at that.
>>
>
> yeah I was planning something similar with 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 21 May 2018 at 11:56, Cillian O'Donnell  wrote:

>
>
> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, 
> wrote:
>
>> On 21 May 2018 at 02:29, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 20 May 2018 at 00:53, Vijay Kumar Banerjee  wrote:

>
>
> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
> wrote:
>
>> It works.. Sorry I was using the right covoar but the wrong
>> rtems-test. Ahh its nice to see the data back in the reports again. Did 
>> you
>> manage to track down 2 exes with the mismatch in symbol size?
>>
> Great! so next is the parsing of the symbol file.
> I couldn't manage to track down the mismatch.
>
> I have pushed these to my master branch.

 The latest update to cov-tester-support branch (please have a look)
 parses the symbol-set ini file from the coverage script. The parsing
 is working but currently it's not generating reports, as covoar
 needs to be updated .

>>>
>>> It's best if covoar reads it's own config file, otherwise it creates a
>>> dependency on the tester. Scanning over the recent changes to covoar there,
>>> it looks like it can already handle multiple sets, so the one ini with
>>> multiple sets in it is the way to go.
>>>
>> Okay, Understood.
>>
>>> Here are the things that I have done and that needs to be
 done in order to generate reports :

 I have added a symbol-sets.ini file and parsed it from the coverage
 script
 this is how it works :


- The ini file can be updated with all the symbols, separated by '
, ' (comma)


>>> This is the way covoar is actually handling it now. You should test a
>>> multi set ini and see if that's working.
>>>
>> Yeah, I have seen it. will try with multiple sets.
>>
>>>
-
- The coverages splits them and makes a list of all the sets
-  The respective libraries are parsed from the libraries section.
- It returns a dict with all the symbols and thir resp. library
addresses.
- The library addresses are absolute so it can be run from anywhere
top of build tree is not necessary.

 This was a good idea but it's just that dependency issue we want to
>>> stay away from. Covoar has something to find the build directory too, it
>>> just hasn't been connected up yet, so running it from the top of the build
>>> directory is ok for the moment.
>>>
>>
>> yes it can find the build directory. I was giving it a shot to do it from
>> the script.
>>
>> If covoar's standalone working is a necessity then it surely needs to be
>> working
>> from covoar and shouldn't depend on the script.
>>
>
> It should be working from covoar and it will.
>
>>
>>> Probably the most pressing thing now is investigating those mismatch in
>>> symbol size.
>>>
>>
>> any advice on where/how to look for it ?
>>
>
> Before what I was doing was examining the objdump of 2 exes, looking there
> on the weekend i think the info messages mentioned which ones were having
> trouble for which symbol. It says something like "couldn't merge coverage
> map for some_symbol because sizes from exe != to size of other_exe. Look at
> the objdump of exe and other_exe, search for some_symbol and compare the
> dissasembly. There'll be more lines in one than the other, nop padding
> probably. Then you had to find a check that was strict enough to chop the
> end of the symbol in question at the right place but not so strict that it
> chopped other symbols in the wrong place. However the method of obtaining
> the symbols has changed, I'll have to have a look over the covoar changes
> tonight to see what would be the equivalent method of checking this now.
> Unless Chris or Joel come back with the answer before then.
>
> Please have a look into this as I'm confused .
>From the messages it seems like there's something with
the base_sp.exe .
I tried to run objdum with -d , I'm getting an error
objdump: can't disassemble for architecture UNKNOWN!
what am I missing ?

Also there will probably be multiple ini's with different collections of
> sets that the user could run so it would be good to give them some method
> of choosing which ini they want, like coverage=score will feed score.ini to
> covoar. You could try have a go at that.
>

yeah I was planning something similar with the script
to let users  choose the sets, and run all by default .
I guess it needs to be done from covoar to avoid dependancy.
I can have look into this.

> This way we can parse all the symbols from the same ini file.

 what needs to be done :

- I have added #FIXME s in the code , those are the small fixes
that
would be needed .
- The covoar needs to be updated. My proposal 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, 
wrote:

> On 21 May 2018 at 02:29, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee 
>>> wrote:
>>>


 On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
 wrote:

> It works.. Sorry I was using the right covoar but the wrong
> rtems-test. Ahh its nice to see the data back in the reports again. Did 
> you
> manage to track down 2 exes with the mismatch in symbol size?
>
 Great! so next is the parsing of the symbol file.
 I couldn't manage to track down the mismatch.

 I have pushed these to my master branch.
>>>
>>> The latest update to cov-tester-support branch (please have a look)
>>> parses the symbol-set ini file from the coverage script. The parsing
>>> is working but currently it's not generating reports, as covoar
>>> needs to be updated .
>>>
>>
>> It's best if covoar reads it's own config file, otherwise it creates a
>> dependency on the tester. Scanning over the recent changes to covoar there,
>> it looks like it can already handle multiple sets, so the one ini with
>> multiple sets in it is the way to go.
>>
> Okay, Understood.
>
>> Here are the things that I have done and that needs to be
>>> done in order to generate reports :
>>>
>>> I have added a symbol-sets.ini file and parsed it from the coverage
>>> script
>>> this is how it works :
>>>
>>>
>>>- The ini file can be updated with all the symbols, separated by ' ,
>>>' (comma)
>>>
>>>
>> This is the way covoar is actually handling it now. You should test a
>> multi set ini and see if that's working.
>>
> Yeah, I have seen it. will try with multiple sets.
>
>>
>>>-
>>>- The coverages splits them and makes a list of all the sets
>>>-  The respective libraries are parsed from the libraries section.
>>>- It returns a dict with all the symbols and thir resp. library
>>>addresses.
>>>- The library addresses are absolute so it can be run from anywhere
>>>top of build tree is not necessary.
>>>
>>> This was a good idea but it's just that dependency issue we want to stay
>> away from. Covoar has something to find the build directory too, it just
>> hasn't been connected up yet, so running it from the top of the build
>> directory is ok for the moment.
>>
>
> yes it can find the build directory. I was giving it a shot to do it from
> the script.
>
> If covoar's standalone working is a necessity then it surely needs to be
> working
> from covoar and shouldn't depend on the script.
>

It should be working from covoar and it will.

>
>> Probably the most pressing thing now is investigating those mismatch in
>> symbol size.
>>
>
> any advice on where/how to look for it ?
>

Before what I was doing was examining the objdump of 2 exes, looking there
on the weekend i think the info messages mentioned which ones were having
trouble for which symbol. It says something like "couldn't merge coverage
map for some_symbol because sizes from exe != to size of other_exe. Look at
the objdump of exe and other_exe, search for some_symbol and compare the
dissasembly. There'll be more lines in one than the other, nop padding
probably. Then you had to find a check that was strict enough to chop the
end of the symbol in question at the right place but not so strict that it
chopped other symbols in the wrong place. However the method of obtaining
the symbols has changed, I'll have to have a look over the covoar changes
tonight to see what would be the equivalent method of checking this now.
Unless Chris or Joel come back with the answer before then.

Also there will probably be multiple ini's with different collections of
sets that the user could run so it would be good to give them some method
of choosing which ini they want, like coverage=score will feed score.ini to
covoar. You could try have a go at that.

> This way we can parse all the symbols from the same ini file.
>>>
>>> what needs to be done :
>>>
>>>- I have added #FIXME s in the code , those are the small fixes that
>>>would be needed .
>>>- The covoar needs to be updated. My proposal is that we can feed the
>>>parsed  dict to the covoar instead of feeding the symbol file and
>>>letting
>>>covoar parse it ( As I mentioned previously).
>>>
>>>
>>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 21 May 2018 at 02:29, Cillian O'Donnell  wrote:

>
>
> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, 
> wrote:
>
>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>>> wrote:
>>>
 It works.. Sorry I was using the right covoar but the wrong rtems-test.
 Ahh its nice to see the data back in the reports again. Did you manage to
 track down 2 exes with the mismatch in symbol size?

>>> Great! so next is the parsing of the symbol file.
>>> I couldn't manage to track down the mismatch.
>>>
>>> I have pushed these to my master branch.
>>
>> The latest update to cov-tester-support branch (please have a look)
>> parses the symbol-set ini file from the coverage script. The parsing
>> is working but currently it's not generating reports, as covoar
>> needs to be updated .
>>
>
> It's best if covoar reads it's own config file, otherwise it creates a
> dependency on the tester. Scanning over the recent changes to covoar there,
> it looks like it can already handle multiple sets, so the one ini with
> multiple sets in it is the way to go.
>
Okay, Understood.

> Here are the things that I have done and that needs to be
>> done in order to generate reports :
>>
>> I have added a symbol-sets.ini file and parsed it from the coverage
>> script
>> this is how it works :
>>
>>
>>- The ini file can be updated with all the symbols, separated by ' ,
>>' (comma)
>>
>>
> This is the way covoar is actually handling it now. You should test a
> multi set ini and see if that's working.
>
Yeah, I have seen it. will try with multiple sets.

>
>>-
>>- The coverages splits them and makes a list of all the sets
>>-  The respective libraries are parsed from the libraries section.
>>- It returns a dict with all the symbols and thir resp. library
>>addresses.
>>- The library addresses are absolute so it can be run from anywhere
>>top of build tree is not necessary.
>>
>> This was a good idea but it's just that dependency issue we want to stay
> away from. Covoar has something to find the build directory too, it just
> hasn't been connected up yet, so running it from the top of the build
> directory is ok for the moment.
>

yes it can find the build directory. I was giving it a shot to do it from
the script.

If covoar's standalone working is a necessity then it surely needs to be
working
from covoar and shouldn't depend on the script.

>
> Probably the most pressing thing now is investigating those mismatch in
> symbol size.
>

any advice on where/how to look for it ?

> This way we can parse all the symbols from the same ini file.
>>
>> what needs to be done :
>>
>>- I have added #FIXME s in the code , those are the small fixes that
>>would be needed .
>>- The covoar needs to be updated. My proposal is that we can feed the
>>parsed  dict to the covoar instead of feeding the symbol file and
>>letting
>>covoar parse it ( As I mentioned previously).
>>
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, 
wrote:

> On 20 May 2018 at 00:53, Vijay Kumar Banerjee 
> wrote:
>
>>
>>
>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>> wrote:
>>
>>> It works.. Sorry I was using the right covoar but the wrong rtems-test.
>>> Ahh its nice to see the data back in the reports again. Did you manage to
>>> track down 2 exes with the mismatch in symbol size?
>>>
>> Great! so next is the parsing of the symbol file.
>> I couldn't manage to track down the mismatch.
>>
>> I have pushed these to my master branch.
>
> The latest update to cov-tester-support branch (please have a look)
> parses the symbol-set ini file from the coverage script. The parsing
> is working but currently it's not generating reports, as covoar
> needs to be updated .
>

It's best if covoar reads it's own config file, otherwise it creates a
dependency on the tester. Scanning over the recent changes to covoar there,
it looks like it can already handle multiple sets, so the one ini with
multiple sets in it is the way to go.

> Here are the things that I have done and that needs to be
> done in order to generate reports :
>
> I have added a symbol-sets.ini file and parsed it from the coverage script
> this is how it works :
>
>
>- The ini file can be updated with all the symbols, separated by ' , '
>(comma)
>
>
This is the way covoar is actually handling it now. You should test a multi
set ini and see if that's working.

>
>-
>- The coverages splits them and makes a list of all the sets
>-  The respective libraries are parsed from the libraries section.
>- It returns a dict with all the symbols and thir resp. library
>addresses.
>- The library addresses are absolute so it can be run from anywhere
>top of build tree is not necessary.
>
> This was a good idea but it's just that dependency issue we want to stay
away from. Covoar has something to find the build directory too, it just
hasn't been connected up yet, so running it from the top of the build
directory is ok for the moment.

Probably the most pressing thing now is investigating those mismatch in
symbol size.

> This way we can parse all the symbols from the same ini file.
>
> what needs to be done :
>
>- I have added #FIXME s in the code , those are the small fixes that
>would be needed .
>- The covoar needs to be updated. My proposal is that we can feed the
>parsed  dict to the covoar instead of feeding the symbol file and
>letting
>covoar parse it ( As I mentioned previously).
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 20 May 2018 at 00:53, Vijay Kumar Banerjee 
wrote:

>
>
> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
> wrote:
>
>> It works.. Sorry I was using the right covoar but the wrong rtems-test.
>> Ahh its nice to see the data back in the reports again. Did you manage to
>> track down 2 exes with the mismatch in symbol size?
>>
> Great! so next is the parsing of the symbol file.
> I couldn't manage to track down the mismatch.
>
> I have pushed these to my master branch.

The latest update to cov-tester-support branch (please have a look)
parses the symbol-set ini file from the coverage script. The parsing
is working but currently it's not generating reports, as covoar
needs to be updated .
Here are the things that I have done and that needs to be
done in order to generate reports :

I have added a symbol-sets.ini file and parsed it from the coverage script
this is how it works :


   - The ini file can be updated with all the symbols, separated by ' , '
   (comma)
   - The coverages splits them and makes a list of all the sets
   -  The respective libraries are parsed from the libraries section.
   - It returns a dict with all the symbols and thir resp. library
   addresses.
   - The library addresses are absolute so it can be run from anywhere
   top of build tree is not necessary.

This way we can parse all the symbols from the same ini file.

what needs to be done :

   - I have added #FIXME s in the code , those are the small fixes that
   would be needed .
   - The covoar needs to be updated. My proposal is that we can feed the
   parsed  dict to the covoar instead of feeding the symbol file and
   letting
   covoar parse it ( As I mentioned previously).
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On Sun, 20 May 2018, 00:45 Cillian O'Donnell,  wrote:

> It works.. Sorry I was using the right covoar but the wrong rtems-test.
> Ahh its nice to see the data back in the reports again. Did you manage to
> track down 2 exes with the mismatch in symbol size?
>
Great! so next is the parsing of the symbol file.
I couldn't manage to track down the mismatch.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

It works.. Sorry I was using the right covoar but the wrong rtems-test. Ahh
its nice to see the data back in the reports again. Did you manage to track
down 2 exes with the mismatch in symbol size?

On 19 May 2018 at 13:59, Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 18:28, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sat, 19 May 2018, 13:28 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
>>> wrote:
>>>
 On 19 May 2018 at 17:50, Vijay Kumar Banerjee  wrote:

> On 19 May 2018 at 17:44, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 19 May 2018 at 16:47, Cillian O'Donnell 
>>> wrote:
>>>

 God these messages again... at least I'm an expert in fixing these
 :) Vijay I'm only seeing the headings in the report on my end using 
 your
 branch. How are you running it and from where? Is there any changes you
 haven't pushed?

>>> I'm rurrning it from top of build tree, the latest change I pushed
>>> was yesterday
>>> 
>>>  and
>>> I haven't made any changes after that. the report seems to be running 
>>> here.
>>>
>>
>> Strange.. if you clean everything away that covoar outputs and run it
>> again, can it still find the data?
>>
> please see the attached image.
> It seems to be working pretty fine.
>
> Can you please try cleaning out everything, fetching my
 cov-tester-support branch, ./waf build install it and then try running
 tester form the top of the build tree?

>>> please run it for samples only, running it for whole testsuites is not
>>> generating proper report currently.
>>>
>>
>> Yeah I'll give it another try when I get home. At the beach at the moment.
>>
> sure , enjoy !
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 19 May 2018 at 18:28, Cillian O'Donnell  wrote:

>
>
> On Sat, 19 May 2018, 13:28 Vijay Kumar Banerjee, 
> wrote:
>
>> On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
>> wrote:
>>
>>> On 19 May 2018 at 17:50, Vijay Kumar Banerjee 
>>> wrote:
>>>
 On 19 May 2018 at 17:44, Cillian O'Donnell 
 wrote:

>
>
> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>> On 19 May 2018 at 16:47, Cillian O'Donnell 
>> wrote:
>>
>>>
>>> God these messages again... at least I'm an expert in fixing these
>>> :) Vijay I'm only seeing the headings in the report on my end using your
>>> branch. How are you running it and from where? Is there any changes you
>>> haven't pushed?
>>>
>> I'm rurrning it from top of build tree, the latest change I pushed
>> was yesterday
>> 
>>  and
>> I haven't made any changes after that. the report seems to be running 
>> here.
>>
>
> Strange.. if you clean everything away that covoar outputs and run it
> again, can it still find the data?
>
 please see the attached image.
 It seems to be working pretty fine.

 Can you please try cleaning out everything, fetching my
>>> cov-tester-support branch, ./waf build install it and then try running
>>> tester form the top of the build tree?
>>>
>> please run it for samples only, running it for whole testsuites is not
>> generating proper report currently.
>>
>
> Yeah I'll give it another try when I get home. At the beach at the moment.
>
sure , enjoy !
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sat, 19 May 2018, 13:28 Vijay Kumar Banerjee, 
wrote:

> On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
> wrote:
>
>> On 19 May 2018 at 17:50, Vijay Kumar Banerjee 
>> wrote:
>>
>>> On 19 May 2018 at 17:44, Cillian O'Donnell 
>>> wrote:
>>>


 On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

> On 19 May 2018 at 16:47, Cillian O'Donnell 
> wrote:
>
>>
>> God these messages again... at least I'm an expert in fixing these :)
>> Vijay I'm only seeing the headings in the report on my end using your
>> branch. How are you running it and from where? Is there any changes you
>> haven't pushed?
>>
> I'm rurrning it from top of build tree, the latest change I pushed was
> yesterday
> 
>  and
> I haven't made any changes after that. the report seems to be running 
> here.
>

 Strange.. if you clean everything away that covoar outputs and run it
 again, can it still find the data?

>>> please see the attached image.
>>> It seems to be working pretty fine.
>>>
>>> Can you please try cleaning out everything, fetching my
>> cov-tester-support branch, ./waf build install it and then try running
>> tester form the top of the build tree?
>>
> please run it for samples only, running it for whole testsuites is not
> generating proper report currently.
>

Yeah I'll give it another try when I get home. At the beach at the moment.

>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 17:50, Vijay Kumar Banerjee 
> wrote:
>
>> On 19 May 2018 at 17:44, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 19 May 2018 at 16:47, Cillian O'Donnell 
 wrote:

>
> God these messages again... at least I'm an expert in fixing these :)
> Vijay I'm only seeing the headings in the report on my end using your
> branch. How are you running it and from where? Is there any changes you
> haven't pushed?
>
 I'm rurrning it from top of build tree, the latest change I pushed was
 yesterday
 
  and
 I haven't made any changes after that. the report seems to be running here.

>>>
>>> Strange.. if you clean everything away that covoar outputs and run it
>>> again, can it still find the data?
>>>
>> please see the attached image.
>> It seems to be working pretty fine.
>>
>> Can you please try cleaning out everything, fetching my
> cov-tester-support branch, ./waf build install it and then try running
> tester form the top of the build tree?
>
please run it for samples only, running it for whole testsuites is not
generating proper report currently.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 19 May 2018 at 17:50, Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 17:44, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 19 May 2018 at 16:47, Cillian O'Donnell 
>>> wrote:
>>>

 God these messages again... at least I'm an expert in fixing these :)
 Vijay I'm only seeing the headings in the report on my end using your
 branch. How are you running it and from where? Is there any changes you
 haven't pushed?

>>> I'm rurrning it from top of build tree, the latest change I pushed was
>>> yesterday
>>> 
>>>  and
>>> I haven't made any changes after that. the report seems to be running here.
>>>
>>
>> Strange.. if you clean everything away that covoar outputs and run it
>> again, can it still find the data?
>>
> please see the attached image.
> It seems to be working pretty fine.
>
> Can you please try cleaning out everything, fetching my cov-tester-support
branch, ./waf build install it and then try running tester form the top of
the build tree?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, 
wrote:

> On 19 May 2018 at 16:47, Cillian O'Donnell  wrote:
>
>>
>> God these messages again... at least I'm an expert in fixing these :)
>> Vijay I'm only seeing the headings in the report on my end using your
>> branch. How are you running it and from where? Is there any changes you
>> haven't pushed?
>>
> I'm rurrning it from top of build tree, the latest change I pushed was
> yesterday
> 
>  and
> I haven't made any changes after that. the report seems to be running here.
>

Strange.. if you clean everything away that covoar outputs and run it
again, can it still find the data?

>
>> Coverage run for score finished successfully.
>>> ---
>>>
>>>
 --joel


>
>> --joel
>>
>>
>>>


>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
>>

>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 19 May 2018 at 16:47, Cillian O'Donnell  wrote:

>
> God these messages again... at least I'm an expert in fixing these :)
> Vijay I'm only seeing the headings in the report on my end using your
> branch. How are you running it and from where? Is there any changes you
> haven't pushed?
>
I'm rurrning it from top of build tree, the latest change I pushed was
yesterday

and
I haven't made any changes after that. the report seems to be running here.

>
> Coverage run for score finished successfully.
>> ---
>>
>>
>>> --joel
>>>
>>>

> --joel
>
>
>>
>>>
>>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On 18 May 2018 at 23:24, Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 03:29, Joel Sherrill  wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 4:53 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, 19 May 2018, 03:06 Joel Sherrill,  wrote:
>>>


 On Fri, May 18, 2018 at 4:01 PM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> On 19 May 2018 at 02:29, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 19 May 2018 at 01:30, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>


 On 18 May 2018 at 19:09, Cillian O'Donnell 
 wrote:

>
>
> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>>
>> On 18 May 2018 at 12:30, Cillian O'Donnell > > wrote:
>>
>>
>>> Cool, you should run it for the full testsuite and take a look
>>> at that report (takes a while.. around 575 tests)
>>>

> When I try to run the full testsuites it gives the following
>> error . What could be causing this ?
>>
>
> If you run the full testsuite without the coverage options, does
> it still happen?
>
 No it seems to run fine without coverage.

>>>
>>> I vaguely remember seeing this before last year, I suspect that when
>>> things are cleared up in coverage.py it will dissappear. So don't worry
>>> about it for now, carry on with what you're doing. What branch are you
>>> working on at the moment?
>>>
>> The path to build directory from the executable path is working now !
>>
>> I'm working in this branch currently, I'll send a patch to all of it
>> together when it starts working.
>>
> I meant to say once the parsing of ini file starts working. the path
> to build directory is already working.
>
>> Please have a look and also suggest improvements where applicable .
>>
>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.
>>
>> after this update, running it on full testsuits doesn't give that
>> error anymore but it has some other issue. The report doesn't shows data
>> only for samples even after running it for full testsuites
>>
>
 Do you have coverage output on all the tests?

>>> I have coverage output on tests under samples/ only .
>>> running it for the whole testsuits gives the same coverage output as
>>> with samples/
>>>

 Is the verbose output indicating that all the tests are being looped
 over?


>
>> and I'm getting this error :
>>
>> -
>> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>>
>

 Cillian must want to purge all memory of this type of message. :)

 This message indicates that a symbol of interest (e.g. a function) has
 one length
 in one executable file and a completely different one in a second.
 Cillian worked
 on one of these last summer which was because the method was padded with
 a different number of nops in each executable. That was supposed to be
 handled
 by covoar but he found a nasty bug.

 This particular one looks like it is for a GCC generated symbol which
 should
 have been ignored in the symbols of interest. My bet is that the way we
 formerly
 got the DesiredSymbols only got real methods. The new way must also be
 picking up some "local" symbols that gcc is generating.

 If we know either of those executables, we should be able to look at
 the
 symbol table with nm and figure out what Chris is pulling in that he
 shouldn't.

 Is this a fatal error or just a "give up" on this symbol in this
 executable?

>>> it doesn't break in the middle. Coverage does run but the report doesn't
>>> look proper
>>>
>>
>> This is an auto-generated symbol by gcc which will be in the middle of a
>> method.
>> DesiredSymbols should be ignoring symbols like this. I don't think seeing
>> them
>> will cause a horrible problem but it is quite likely that the method(s)
>> these are
>> seen in will have quite incorrect results.
>>
>> If running on samples looks OK, try running coverage from just tmtests and
>> see if that is better. You need to find a set small enough to trip the
>> problem
>> but easy to analyse.
>>
> Coverage from tmtests looks OK .
> psxtmtests , psxtests, libtests gives the same error and doesn't show
> proper coverage report.
>
> Also, I can see these INFO lines even with the ones that are showing
> proper coverage output
>
> 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 19 May 2018 at 04:26, Joel Sherrill  wrote:

> If you run nm on some of the executables, do you see the
> Is symbol? We need to.know its type.
>

I did this on the testsuites
find -iname '*.exe' -exec nm -A '{}' \; | grep '\'

which returned nothing .
am I using the right command ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

If you run nm on some of the executables, do you see the
Is symbol? We need to.know its type.

On Fri, May 18, 2018, 5:24 PM Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 03:29, Joel Sherrill  wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 4:53 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, 19 May 2018, 03:06 Joel Sherrill,  wrote:
>>>


 On Fri, May 18, 2018 at 4:01 PM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> On 19 May 2018 at 02:29, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 19 May 2018 at 01:30, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>


 On 18 May 2018 at 19:09, Cillian O'Donnell 
 wrote:

>
>
> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>>
>> On 18 May 2018 at 12:30, Cillian O'Donnell > > wrote:
>>
>>
>>> Cool, you should run it for the full testsuite and take a look
>>> at that report (takes a while.. around 575 tests)
>>>

> When I try to run the full testsuites it gives the following
>> error . What could be causing this ?
>>
>
> If you run the full testsuite without the coverage options, does
> it still happen?
>
 No it seems to run fine without coverage.

>>>
>>> I vaguely remember seeing this before last year, I suspect that when
>>> things are cleared up in coverage.py it will dissappear. So don't worry
>>> about it for now, carry on with what you're doing. What branch are you
>>> working on at the moment?
>>>
>> The path to build directory from the executable path is working now !
>>
>> I'm working in this branch currently, I'll send a patch to all of it
>> together when it starts working.
>>
> I meant to say once the parsing of ini file starts working. the path
> to build directory is already working.
>
>> Please have a look and also suggest improvements where applicable .
>>
>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.
>>
>> after this update, running it on full testsuits doesn't give that
>> error anymore but it has some other issue. The report doesn't shows data
>> only for samples even after running it for full testsuites
>>
>
 Do you have coverage output on all the tests?

>>> I have coverage output on tests under samples/ only .
>>> running it for the whole testsuits gives the same coverage output as
>>> with samples/
>>>

 Is the verbose output indicating that all the tests are being looped
 over?


>
>> and I'm getting this error :
>>
>> -
>> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>>
>

 Cillian must want to purge all memory of this type of message. :)

 This message indicates that a symbol of interest (e.g. a function) has
 one length
 in one executable file and a completely different one in a second.
 Cillian worked
 on one of these last summer which was because the method was padded with
 a different number of nops in each executable. That was supposed to be
 handled
 by covoar but he found a nasty bug.

 This particular one looks like it is for a GCC generated symbol which
 should
 have been ignored in the symbols of interest. My bet is that the way we
 formerly
 got the DesiredSymbols only got real methods. The new way must also be
 picking up some "local" symbols that gcc is generating.

 If we know either of those executables, we should be able to look at
 the
 symbol table with nm and figure out what Chris is pulling in that he
 shouldn't.

 Is this a fatal error or just a "give up" on this symbol in this
 executable?

>>> it doesn't break in the middle. Coverage does run but the report doesn't
>>> look proper
>>>
>>
>> This is an auto-generated symbol by gcc which will be in the middle of a
>> method.
>> DesiredSymbols should be ignoring symbols like this. I don't think seeing
>> them
>> will cause a horrible problem but it is quite likely that the method(s)
>> these are
>> seen in will have quite incorrect results.
>>
>> If running on samples looks OK, try running coverage from just tmtests and
>> see if that is better. You need to find a set small enough to trip the
>> problem
>> but easy to analyse.
>>
> Coverage from tmtests looks OK .
> psxtmtests , psxtests, libtests gives the same error and doesn't show
> proper coverage report.
>

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 19 May 2018 at 03:29, Joel Sherrill  wrote:

>
>
> On Fri, May 18, 2018 at 4:53 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On Sat, 19 May 2018, 03:06 Joel Sherrill,  wrote:
>>
>>>
>>>
>>> On Fri, May 18, 2018 at 4:01 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 19 May 2018 at 02:29, Vijay Kumar Banerjee  wrote:

> On 19 May 2018 at 01:30, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On 18 May 2018 at 19:09, Cillian O'Donnell 
>>> wrote:
>>>


 On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

>
> On 18 May 2018 at 12:30, Cillian O'Donnell 
> wrote:
>
>
>> Cool, you should run it for the full testsuite and take a look at
>> that report (takes a while.. around 575 tests)
>>
>>>
 When I try to run the full testsuites it gives the following
> error . What could be causing this ?
>

 If you run the full testsuite without the coverage options, does it
 still happen?

>>> No it seems to run fine without coverage.
>>>
>>
>> I vaguely remember seeing this before last year, I suspect that when
>> things are cleared up in coverage.py it will dissappear. So don't worry
>> about it for now, carry on with what you're doing. What branch are you
>> working on at the moment?
>>
> The path to build directory from the executable path is working now !
>
> I'm working in this branch currently, I'll send a patch to all of it
> together when it starts working.
>
 I meant to say once the parsing of ini file starts working. the path to
 build directory is already working.

> Please have a look and also suggest improvements where applicable .
>
> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.
>
> after this update, running it on full testsuits doesn't give that
> error anymore but it has some other issue. The report doesn't shows data
> only for samples even after running it for full testsuites
>

>>> Do you have coverage output on all the tests?
>>>
>> I have coverage output on tests under samples/ only .
>> running it for the whole testsuits gives the same coverage output as with
>> samples/
>>
>>>
>>> Is the verbose output indicating that all the tests are being looped
>>> over?
>>>
>>>

> and I'm getting this error :
>
> -
> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>

>>>
>>> Cillian must want to purge all memory of this type of message. :)
>>>
>>> This message indicates that a symbol of interest (e.g. a function) has
>>> one length
>>> in one executable file and a completely different one in a second.
>>> Cillian worked
>>> on one of these last summer which was because the method was padded with
>>> a different number of nops in each executable. That was supposed to be
>>> handled
>>> by covoar but he found a nasty bug.
>>>
>>> This particular one looks like it is for a GCC generated symbol which
>>> should
>>> have been ignored in the symbols of interest. My bet is that the way we
>>> formerly
>>> got the DesiredSymbols only got real methods. The new way must also be
>>> picking up some "local" symbols that gcc is generating.
>>>
>>> If we know either of those executables, we should be able to look at the
>>> symbol table with nm and figure out what Chris is pulling in that he
>>> shouldn't.
>>>
>>> Is this a fatal error or just a "give up" on this symbol in this
>>> executable?
>>>
>> it doesn't break in the middle. Coverage does run but the report doesn't
>> look proper
>>
>
> This is an auto-generated symbol by gcc which will be in the middle of a
> method.
> DesiredSymbols should be ignoring symbols like this. I don't think seeing
> them
> will cause a horrible problem but it is quite likely that the method(s)
> these are
> seen in will have quite incorrect results.
>
> If running on samples looks OK, try running coverage from just tmtests and
> see if that is better. You need to find a set small enough to trip the
> problem
> but easy to analyse.
>
Coverage from tmtests looks OK .
psxtmtests , psxtests, libtests gives the same error and doesn't show
proper coverage report.

Also, I can see these INFO lines even with the ones that are showing proper
coverage output

--
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
CSWTCH.1 because the sizes are different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Thread_queue_Operations_default 

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

On Fri, May 18, 2018 at 4:53 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

>
>
> On Sat, 19 May 2018, 03:06 Joel Sherrill,  wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 4:01 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 19 May 2018 at 02:29, Vijay Kumar Banerjee 
>>> wrote:
>>>
 On 19 May 2018 at 01:30, Cillian O'Donnell 
 wrote:

>
>
> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>>
>>
>> On 18 May 2018 at 19:09, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>

 On 18 May 2018 at 12:30, Cillian O'Donnell 
 wrote:


> Cool, you should run it for the full testsuite and take a look at
> that report (takes a while.. around 575 tests)
>
>>
>>> When I try to run the full testsuites it gives the following
 error . What could be causing this ?

>>>
>>> If you run the full testsuite without the coverage options, does it
>>> still happen?
>>>
>> No it seems to run fine without coverage.
>>
>
> I vaguely remember seeing this before last year, I suspect that when
> things are cleared up in coverage.py it will dissappear. So don't worry
> about it for now, carry on with what you're doing. What branch are you
> working on at the moment?
>
 The path to build directory from the executable path is working now !

 I'm working in this branch currently, I'll send a patch to all of it
 together when it starts working.

>>> I meant to say once the parsing of ini file starts working. the path to
>>> build directory is already working.
>>>
 Please have a look and also suggest improvements where applicable .

 https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.

 after this update, running it on full testsuits doesn't give that error
 anymore but it has some other issue. The report doesn't shows data only for
 samples even after running it for full testsuites

>>>
>> Do you have coverage output on all the tests?
>>
> I have coverage output on tests under samples/ only .
> running it for the whole testsuits gives the same coverage output as with
> samples/
>
>>
>> Is the verbose output indicating that all the tests are being looped over?
>>
>>
>>>
 and I'm getting this error :

 -
 ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)

>>>
>>
>> Cillian must want to purge all memory of this type of message. :)
>>
>> This message indicates that a symbol of interest (e.g. a function) has
>> one length
>> in one executable file and a completely different one in a second.
>> Cillian worked
>> on one of these last summer which was because the method was padded with
>> a different number of nops in each executable. That was supposed to be
>> handled
>> by covoar but he found a nasty bug.
>>
>> This particular one looks like it is for a GCC generated symbol which
>> should
>> have been ignored in the symbols of interest. My bet is that the way we
>> formerly
>> got the DesiredSymbols only got real methods. The new way must also be
>> picking up some "local" symbols that gcc is generating.
>>
>> If we know either of those executables, we should be able to look at the
>> symbol table with nm and figure out what Chris is pulling in that he
>> shouldn't.
>>
>> Is this a fatal error or just a "give up" on this symbol in this
>> executable?
>>
> it doesn't break in the middle. Coverage does run but the report doesn't
> look proper
>

This is an auto-generated symbol by gcc which will be in the middle of a
method.
DesiredSymbols should be ignoring symbols like this. I don't think seeing
them
will cause a horrible problem but it is quite likely that the method(s)
these are
seen in will have quite incorrect results.

If running on samples looks OK, try running coverage from just tmtests and
see if that is better. You need to find a set small enough to trip the
problem
but easy to analyse.

--joel


>
>> --joel
>>
>>
>>>


>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On Sat, 19 May 2018, 03:06 Joel Sherrill,  wrote:

>
>
> On Fri, May 18, 2018 at 4:01 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 19 May 2018 at 02:29, Vijay Kumar Banerjee 
>> wrote:
>>
>>> On 19 May 2018 at 01:30, Cillian O'Donnell 
>>> wrote:
>>>


 On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

>
>
> On 18 May 2018 at 19:09, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>> On 18 May 2018 at 12:30, Cillian O'Donnell 
>>> wrote:
>>>
>>>
 Cool, you should run it for the full testsuite and take a look at
 that report (takes a while.. around 575 tests)

>
>> When I try to run the full testsuites it gives the following
>>> error . What could be causing this ?
>>>
>>
>> If you run the full testsuite without the coverage options, does it
>> still happen?
>>
> No it seems to run fine without coverage.
>

 I vaguely remember seeing this before last year, I suspect that when
 things are cleared up in coverage.py it will dissappear. So don't worry
 about it for now, carry on with what you're doing. What branch are you
 working on at the moment?

>>> The path to build directory from the executable path is working now !
>>>
>>> I'm working in this branch currently, I'll send a patch to all of it
>>> together when it starts working.
>>>
>> I meant to say once the parsing of ini file starts working. the path to
>> build directory is already working.
>>
>>> Please have a look and also suggest improvements where applicable .
>>>
>>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.
>>>
>>> after this update, running it on full testsuits doesn't give that error
>>> anymore but it has some other issue. The report doesn't shows data only for
>>> samples even after running it for full testsuites
>>>
>>
> Do you have coverage output on all the tests?
>
I have coverage output on tests under samples/ only .
running it for the whole testsuits gives the same coverage output as with
samples/

>
> Is the verbose output indicating that all the tests are being looped over?
>
>
>>
>>> and I'm getting this error :
>>>
>>> -
>>> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>>>
>>
>
> Cillian must want to purge all memory of this type of message. :)
>
> This message indicates that a symbol of interest (e.g. a function) has one
> length
> in one executable file and a completely different one in a second. Cillian
> worked
> on one of these last summer which was because the method was padded with
> a different number of nops in each executable. That was supposed to be
> handled
> by covoar but he found a nasty bug.
>
> This particular one looks like it is for a GCC generated symbol which
> should
> have been ignored in the symbols of interest. My bet is that the way we
> formerly
> got the DesiredSymbols only got real methods. The new way must also be
> picking up some "local" symbols that gcc is generating.
>
> If we know either of those executables, we should be able to look at the
> symbol table with nm and figure out what Chris is pulling in that he
> shouldn't.
>
> Is this a fatal error or just a "give up" on this symbol in this
> executable?
>
it doesn't break in the middle. Coverage does run but the report doesn't
look proper

>
> --joel
>
>
>>
>>>
>>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

On Fri, May 18, 2018 at 4:01 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> On 19 May 2018 at 02:29, Vijay Kumar Banerjee 
> wrote:
>
>> On 19 May 2018 at 01:30, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>


 On 18 May 2018 at 19:09, Cillian O'Donnell 
 wrote:

>
>
> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>>
>> On 18 May 2018 at 12:30, Cillian O'Donnell 
>> wrote:
>>
>>
>>> Cool, you should run it for the full testsuite and take a look at
>>> that report (takes a while.. around 575 tests)
>>>

> When I try to run the full testsuites it gives the following error
>> . What could be causing this ?
>>
>
> If you run the full testsuite without the coverage options, does it
> still happen?
>
 No it seems to run fine without coverage.

>>>
>>> I vaguely remember seeing this before last year, I suspect that when
>>> things are cleared up in coverage.py it will dissappear. So don't worry
>>> about it for now, carry on with what you're doing. What branch are you
>>> working on at the moment?
>>>
>> The path to build directory from the executable path is working now !
>>
>> I'm working in this branch currently, I'll send a patch to all of it
>> together when it starts working.
>>
> I meant to say once the parsing of ini file starts working. the path to
> build directory is already working.
>
>> Please have a look and also suggest improvements where applicable .
>>
>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.
>>
>> after this update, running it on full testsuits doesn't give that error
>> anymore but it has some other issue. The report doesn't shows data only for
>> samples even after running it for full testsuites
>>
>
Do you have coverage output on all the tests?

Is the verbose output indicating that all the tests are being looped over?


>
>> and I'm getting this error :
>>
>> -
>> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>>
>

Cillian must want to purge all memory of this type of message. :)

This message indicates that a symbol of interest (e.g. a function) has one
length
in one executable file and a completely different one in a second. Cillian
worked
on one of these last summer which was because the method was padded with
a different number of nops in each executable. That was supposed to be
handled
by covoar but he found a nasty bug.

This particular one looks like it is for a GCC generated symbol which should
have been ignored in the symbols of interest. My bet is that the way we
formerly
got the DesiredSymbols only got real methods. The new way must also be
picking up some "local" symbols that gcc is generating.

If we know either of those executables, we should be able to look at the
symbol table with nm and figure out what Chris is pulling in that he
shouldn't.

Is this a fatal error or just a "give up" on this symbol in this executable?

--joel


>
>>
>>
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 19 May 2018 at 02:29, Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 01:30, Cillian O'Donnell  wrote:
>
>>
>>
>> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On 18 May 2018 at 19:09, Cillian O'Donnell 
>>> wrote:
>>>


 On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

>
> On 18 May 2018 at 12:30, Cillian O'Donnell 
> wrote:
>
>
>> Cool, you should run it for the full testsuite and take a look at
>> that report (takes a while.. around 575 tests)
>>
>>>
 When I try to run the full testsuites it gives the following error
> . What could be causing this ?
>

 If you run the full testsuite without the coverage options, does it
 still happen?

>>> No it seems to run fine without coverage.
>>>
>>
>> I vaguely remember seeing this before last year, I suspect that when
>> things are cleared up in coverage.py it will dissappear. So don't worry
>> about it for now, carry on with what you're doing. What branch are you
>> working on at the moment?
>>
> The path to build directory from the executable path is working now !
>
> I'm working in this branch currently, I'll send a patch to all of it
> together when it starts working.
>
I meant to say once the parsing of ini file starts working. the path to
build directory is already working.

> Please have a look and also suggest improvements where applicable .
>
> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.
>
> after this update, running it on full testsuits doesn't give that error
> anymore but it has some other issue. The report doesn't shows data only for
> samples even after running it for full testsuites
>
> and I'm getting this error :
>
> -
> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 19 May 2018 at 01:30, Cillian O'Donnell  wrote:

>
>
> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, 
> wrote:
>
>>
>>
>> On 18 May 2018 at 19:09, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>

 On 18 May 2018 at 12:30, Cillian O'Donnell 
 wrote:


> Cool, you should run it for the full testsuite and take a look at that
> report (takes a while.. around 575 tests)
>
>>
>>> When I try to run the full testsuites it gives the following error .
 What could be causing this ?

>>>
>>> If you run the full testsuite without the coverage options, does it
>>> still happen?
>>>
>> No it seems to run fine without coverage.
>>
>
> I vaguely remember seeing this before last year, I suspect that when
> things are cleared up in coverage.py it will dissappear. So don't worry
> about it for now, carry on with what you're doing. What branch are you
> working on at the moment?
>
The path to build directory from the executable path is working now !

I'm working in this branch currently, I'll send a patch to all of it
together when it starts working. Please have a look and also suggest
improvements where applicable .

https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.

after this update, running it on full testsuits doesn't give that error
anymore but it has some other issue. The report doesn't shows data only for
samples even after running it for full testsuites

and I'm getting this error :

-
ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, 
wrote:

>
>
> On 18 May 2018 at 19:09, Cillian O'Donnell  wrote:
>
>>
>>
>> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>> On 18 May 2018 at 12:30, Cillian O'Donnell 
>>> wrote:
>>>
>>>
 Cool, you should run it for the full testsuite and take a look at that
 report (takes a while.. around 575 tests)

>
>> When I try to run the full testsuites it gives the following error .
>>> What could be causing this ?
>>>
>>
>> If you run the full testsuite without the coverage options, does it still
>> happen?
>>
> No it seems to run fine without coverage.
>

I vaguely remember seeing this before last year, I suspect that when things
are cleared up in coverage.py it will dissappear. So don't worry about it
for now, carry on with what you're doing. What branch are you working on at
the moment?

>
>>>  ---
>>> self.__bootstrap_inner()
>>>   File "/usr/lib64/python2.7/threading.py", line 817, in
>>> __bootstrap_inner
>>> (self.name, _format_exc()))
>>> IOError: [Errno 11] Resource temporarily unavailable
>>>
>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 18 May 2018 at 19:09, Cillian O'Donnell  wrote:

>
>
> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, 
> wrote:
>
>>
>> On 18 May 2018 at 12:30, Cillian O'Donnell  wrote:
>>
>>
>>> Cool, you should run it for the full testsuite and take a look at that
>>> report (takes a while.. around 575 tests)
>>>

> When I try to run the full testsuites it gives the following error .
>> What could be causing this ?
>>
>
> If you run the full testsuite without the coverage options, does it still
> happen?
>
No it seems to run fine without coverage.

>
>>  ---
>> self.__bootstrap_inner()
>>   File "/usr/lib64/python2.7/threading.py", line 817, in
>> __bootstrap_inner
>> (self.name, _format_exc()))
>> IOError: [Errno 11] Resource temporarily unavailable
>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, 
wrote:

>
> On 18 May 2018 at 12:30, Cillian O'Donnell  wrote:
>
>
>> Cool, you should run it for the full testsuite and take a look at that
>> report (takes a while.. around 575 tests)
>>
>>>
 When I try to run the full testsuites it gives the following error .
> What could be causing this ?
>

If you run the full testsuite without the coverage options, does it still
happen?

>
>  ---
> self.__bootstrap_inner()
>   File "/usr/lib64/python2.7/threading.py", line 817, in __bootstrap_inner
> (self.name, _format_exc()))
> IOError: [Errno 11] Resource temporarily unavailable
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 18 May 2018 at 12:30, Cillian O'Donnell  wrote:


> Cool, you should run it for the full testsuite and take a look at that
> report (takes a while.. around 575 tests)
>
>>
>>> When I try to run the full testsuites it gives the following error .
What could be causing this ?

 ---
self.__bootstrap_inner()
  File "/usr/lib64/python2.7/threading.py", line 817, in __bootstrap_inner
(self.name, _format_exc()))
IOError: [Errno 11] Resource temporarily unavailable
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Fri, 18 May 2018, 07:46 Vijay Kumar Banerjee, 
wrote:

> On Fri, 18 May 2018, 11:52 Cillian O'Donnell, 
> wrote:
>
>>
>>
>> On Thu, 17 May 2018, 21:32 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> hello,
>>>
>>> I have attached the html report !
>>>
>>
>> Report looks good! Well done. Was that just for samples. Did the other
>> sections appear in the report if you click through the links?
>>
> yes it was for samples and yes the links are working
>

Cool, you should run it for the full testsuite and take a look at that
report (takes a while.. around 575 tests)

>
>> Well it looks good but I hardcoded the paths, at least that gave the
>>> proper idea of what exactly needs to be done. Now I understand why
>>> --rtems-builddir stayed there for a long time , it makes the job simple .
>>>
>>> Here's a point that needs discussion :
>>>
>>> 1. the coverage.py in it's current state(before the updates I made
>>> today) tries to parse the score-symbols.ini file (class
>>> symbols_configuration()) , which is not needed after the recent updates to
>>> covoar which makes it work from covoar itself. I have just removed that
>>> class for now .
>>>
>>
>> Yeah there could definitely be some sections that might be completely
>> removed now. I left most things in because there's still some things
>> undecided. I'm not sure how we'll handle multiple sets now. Will we have
>> all sets in one .ini and create a new .ini for every different collection
>> of sets. Or will we define each set in one .ini each and pass multiple
>> .ini's to covoar. How will the user pick which sets he's interested in?
>> Pass names to coverage argument maybe
>>
>> --coverage=score,core..etc
>>
> The script used to treat it like a collection of sets. I was thinking of
> running a loop over all the keys under a tag [symbol-sets] and getting
> their respective libraries .
> Is it for the user to decide which sets to use?
>

It's probably best to give some options to change the sets under test.

> Do we need to have a separate ini file for each set?
>

It can work either way, it's more a matter of which is the better design.

>
>> Chris when you redefined the config logic, how did imagine multiple sets
>> working?
>>
>>>
>>> One thing can be done, which I think will solve parsing of the absolute
>>> path of the library as well. It is to implement the the logic that Chris
>>> used in covoar.cc , into the python script for coverage . Then we can do an
>>> os.path.abspath() for the absolute path and the extract the directory name
>>> from there for the html report from the same place. Can we do it that way ?
>>>
>>
>> Sounds like a good plan. Definitely give it a shot.
>>
> it would be good if it works out, but again , the main challenge is the
> path to build directory. :p
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On Fri, 18 May 2018, 11:52 Cillian O'Donnell,  wrote:

>
>
> On Thu, 17 May 2018, 21:32 Vijay Kumar Banerjee, 
> wrote:
>
>> hello,
>>
>> I have attached the html report !
>>
>
> Report looks good! Well done. Was that just for samples. Did the other
> sections appear in the report if you click through the links?
>
yes it was for samples and yes the links are working .

>
> Well it looks good but I hardcoded the paths, at least that gave the
>> proper idea of what exactly needs to be done. Now I understand why
>> --rtems-builddir stayed there for a long time , it makes the job simple .
>>
>> Here's a point that needs discussion :
>>
>> 1. the coverage.py in it's current state(before the updates I made today)
>> tries to parse the score-symbols.ini file (class symbols_configuration()) ,
>> which is not needed after the recent updates to covoar which makes it work
>> from covoar itself. I have just removed that class for now .
>>
>
> Yeah there could definitely be some sections that might be completely
> removed now. I left most things in because there's still some things
> undecided. I'm not sure how we'll handle multiple sets now. Will we have
> all sets in one .ini and create a new .ini for every different collection
> of sets. Or will we define each set in one .ini each and pass multiple
> .ini's to covoar. How will the user pick which sets he's interested in?
> Pass names to coverage argument maybe
>
> --coverage=score,core..etc
>
The script used to treat it like a collection of sets. I was thinking of
running a loop over all the keys under a tag [symbol-sets] and getting
their respective libraries .
Is it for the user to decide which sets to use?
Do we need to have a separate ini file for each set?

>
> Chris when you redefined the config logic, how did imagine multiple sets
> working?
>
>>
>> One thing can be done, which I think will solve parsing of the absolute
>> path of the library as well. It is to implement the the logic that Chris
>> used in covoar.cc , into the python script for coverage . Then we can do an
>> os.path.abspath() for the absolute path and the extract the directory name
>> from there for the html report from the same place. Can we do it that way ?
>>
>
> Sounds like a good plan. Definitely give it a shot.
>
it would be good if it works out, but again , the main challenge is the
path to build directory. :p
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Thu, 17 May 2018, 21:32 Vijay Kumar Banerjee, 
wrote:

> hello,
>
> I have attached the html report !
>

Report looks good! Well done. Was that just for samples. Did the other
sections appear in the report if you click through the links?

Well it looks good but I hardcoded the paths, at least that gave the proper
> idea of what exactly needs to be done. Now I understand why
> --rtems-builddir stayed there for a long time , it makes the job simple .
>
> Here's a point that needs discussion :
>
> 1. the coverage.py in it's current state(before the updates I made today)
> tries to parse the score-symbols.ini file (class symbols_configuration()) ,
> which is not needed after the recent updates to covoar which makes it work
> from covoar itself. I have just removed that class for now .
>

Yeah there could definitely be some sections that might be completely
removed now. I left most things in because there's still some things
undecided. I'm not sure how we'll handle multiple sets now. Will we have
all sets in one .ini and create a new .ini for every different collection
of sets. Or will we define each set in one .ini each and pass multiple
.ini's to covoar. How will the user pick which sets he's interested in?
Pass names to coverage argument maybe

--coverage=score,core..etc

Chris when you redefined the config logic, how did imagine multiple sets
working?

>
> One thing can be done, which I think will solve parsing of the absolute
> path of the library as well. It is to implement the the logic that Chris
> used in covoar.cc , into the python script for coverage . Then we can do an
> os.path.abspath() for the absolute path and the extract the directory name
> from there for the html report from the same place. Can we do it that way ?
>

Sounds like a good plan. Definitely give it a shot.

>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Chris Johns]

On 18/5/18 8:32 am, Vijay Kumar Banerjee wrote:>
> One thing can be done, which I think will solve parsing of the absolute path 
> of
> the library as well. It is to implement the the logic that Chris used in
> covoar.cc , into the python script for coverage . Then we can do an
> os.path.abspath() for the absolute path and the extract the directory name 
> from
> there for the html report from the same place. Can we do it that way ? 
> 

Sure, please try and see how it goes?

This may evolve and if and when that happens we can update both places.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

hello,

I have attached the html report !
Well it looks good but I hardcoded the paths, at least that gave the proper
idea of what exactly needs to be done. Now I understand why
--rtems-builddir stayed there for a long time , it makes the job simple .

Here's a point that needs discussion :

1. the coverage.py in it's current state(before the updates I made today)
tries to parse the score-symbols.ini file (class symbols_configuration()) ,
which is not needed after the recent updates to covoar which makes it work
from covoar itself. I have just removed that class for now .

One thing can be done, which I think will solve parsing of the absolute
path of the library as well. It is to implement the the logic that Chris
used in covoar.cc , into the python script for coverage . Then we can do an
os.path.abspath() for the absolute path and the extract the directory name
from there for the html report from the same place. Can we do it that way ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On Mon, 14 May 2018, 23:24 Cillian O'Donnell,  wrote:

>
>
> On Mon, 14 May 2018, 09:50 Vijay Kumar Banerjee, 
> wrote:
>
>> On 14 May 2018 at 12:10, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 14 May 2018 at 02:15, Cillian O'Donnell 
 wrote:

> ---
>  tester/covoar/covoar.cc | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
> index 5c87402..c6b0589 100644
> --- a/tester/covoar/covoar.cc
> +++ b/tester/covoar/covoar.cc
> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPrefix.empty()) {
>buildPrefix = *pri;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPrefix != *pri) {
>  fail = "executable build prefix does not match: " +
> buildPrefix;
>  break;
>}
> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPath.empty()) {
>buildPath = thisBuildPath;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPath != thisBuildPath) {
>  fail = "executable build path does not match: " +
> buildPath;
>}
>  }
> @@ -316,11 +316,7 @@ int main(
>  std::cerr << "warning: Unable to read executable: " <<
> argv[i] << std::endl;
>} else {
>  coverageFileName = argv[i];
> -coverageFileName.replace(
> -  coverageFileName.length() - executableExtension.size(),
> -  executableExtension.size(),
> -  coverageExtension
> -);
> +coverageFileName.append( "." + coverageExtension );
>
>  if (!FileIsReadable( coverageFileName.c_str() )) {
>std::cerr << "warning: Unable to read coverage file: " <<
> coverageFileName
> --
> 2.7.4
>
> This worked !

>>>
>>> Cool, looks like we're onto fixing the reports then. If you take a look
>>> at report.html only the headings are there. I think what might be wrong
>>> there is it's just searching in the wrong place for the results. The fix
>>> for that will lie in coverage.py. Warning about coverage.py, there could be
>>> whole sections in there that might just be deleted, it's still being
>>> reorganized.
>>>
>>> Are you working on it ?
>>
>
> Yeah I'll be hacking away at that, won't make much of a dent till the
> weekend though.
>
>> Also the absolute path needs to be parsed form the score-symbol.ini for
>> running it from out of the build tree
>>
>
> This is true.
>
>> Or seeing as covoar is in good shape now and I think the txt report is ok
>>> (you should check and make sure of that). You could move onto gcov, lcov
>>> stuff. Figure out the state of the gcov support in covoar, generate gcov
>>> reports, compare the results.
>>>
>> I'll creat a new thread for gcov report then.
>>
>
> Cool, you're gonna do the gcov stuff then.
>
yeah. hopefully it will show some movement soon. :)

> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>


>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 14 May 2018, 09:50 Vijay Kumar Banerjee, 
wrote:

> On 14 May 2018 at 12:10, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 14 May 2018 at 02:15, Cillian O'Donnell 
>>> wrote:
>>>
 ---
  tester/covoar/covoar.cc | 10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

 diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
 index 5c87402..c6b0589 100644
 --- a/tester/covoar/covoar.cc
 +++ b/tester/covoar/covoar.cc
 @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
 executablesToAnalyze,
  if (buildPrefix.empty()) {
buildPrefix = *pri;
  } else {
 -  if (buildBSP != *pri) {
 +  if (buildPrefix != *pri) {
  fail = "executable build prefix does not match: " +
 buildPrefix;
  break;
}
 @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
 executablesToAnalyze,
  if (buildPath.empty()) {
buildPath = thisBuildPath;
  } else {
 -  if (buildBSP != *pri) {
 +  if (buildPath != thisBuildPath) {
  fail = "executable build path does not match: " +
 buildPath;
}
  }
 @@ -316,11 +316,7 @@ int main(
  std::cerr << "warning: Unable to read executable: " << argv[i]
 << std::endl;
} else {
  coverageFileName = argv[i];
 -coverageFileName.replace(
 -  coverageFileName.length() - executableExtension.size(),
 -  executableExtension.size(),
 -  coverageExtension
 -);
 +coverageFileName.append( "." + coverageExtension );

  if (!FileIsReadable( coverageFileName.c_str() )) {
std::cerr << "warning: Unable to read coverage file: " <<
 coverageFileName
 --
 2.7.4

 This worked !
>>>
>>
>> Cool, looks like we're onto fixing the reports then. If you take a look
>> at report.html only the headings are there. I think what might be wrong
>> there is it's just searching in the wrong place for the results. The fix
>> for that will lie in coverage.py. Warning about coverage.py, there could be
>> whole sections in there that might just be deleted, it's still being
>> reorganized.
>>
>> Are you working on it ?
>

Yeah I'll be hacking away at that, won't make much of a dent till the
weekend though.

> Also the absolute path needs to be parsed form the score-symbol.ini for
> running it from out of the build tree
>

This is true.

> Or seeing as covoar is in good shape now and I think the txt report is ok
>> (you should check and make sure of that). You could move onto gcov, lcov
>> stuff. Figure out the state of the gcov support in covoar, generate gcov
>> reports, compare the results.
>>
> I'll creat a new thread for gcov report then.
>

Cool, you're gonna do the gcov stuff then.

> ___
 devel mailing list
 devel@rtems.org
 http://lists.rtems.org/mailman/listinfo/devel

>>>
>>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 14 May 2018, 16:46 Joel Sherrill,  wrote:

> I'll commit this once there is a log message. :)
>

You want the word 'Fix' is it?... :)

>
> On Sun, May 13, 2018 at 3:45 PM, Cillian O'Donnell 
> wrote:
>
>> ---
>>  tester/covoar/covoar.cc | 10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
>> index 5c87402..c6b0589 100644
>> --- a/tester/covoar/covoar.cc
>> +++ b/tester/covoar/covoar.cc
>> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPrefix.empty()) {
>>buildPrefix = *pri;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPrefix != *pri) {
>>  fail = "executable build prefix does not match: " +
>> buildPrefix;
>>  break;
>>}
>> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPath.empty()) {
>>buildPath = thisBuildPath;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPath != thisBuildPath) {
>>  fail = "executable build path does not match: " + buildPath;
>>}
>>  }
>> @@ -316,11 +316,7 @@ int main(
>>  std::cerr << "warning: Unable to read executable: " << argv[i]
>> << std::endl;
>>} else {
>>  coverageFileName = argv[i];
>> -coverageFileName.replace(
>> -  coverageFileName.length() - executableExtension.size(),
>> -  executableExtension.size(),
>> -  coverageExtension
>> -);
>> +coverageFileName.append( "." + coverageExtension );
>>
>>  if (!FileIsReadable( coverageFileName.c_str() )) {
>>std::cerr << "warning: Unable to read coverage file: " <<
>> coverageFileName
>> --
>> 2.7.4
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Joel Sherrill]

I'll commit this once there is a log message. :)

On Sun, May 13, 2018 at 3:45 PM, Cillian O'Donnell 
wrote:

> ---
>  tester/covoar/covoar.cc | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
> index 5c87402..c6b0589 100644
> --- a/tester/covoar/covoar.cc
> +++ b/tester/covoar/covoar.cc
> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPrefix.empty()) {
>buildPrefix = *pri;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPrefix != *pri) {
>  fail = "executable build prefix does not match: " +
> buildPrefix;
>  break;
>}
> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPath.empty()) {
>buildPath = thisBuildPath;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPath != thisBuildPath) {
>  fail = "executable build path does not match: " + buildPath;
>}
>  }
> @@ -316,11 +316,7 @@ int main(
>  std::cerr << "warning: Unable to read executable: " << argv[i] <<
> std::endl;
>} else {
>  coverageFileName = argv[i];
> -coverageFileName.replace(
> -  coverageFileName.length() - executableExtension.size(),
> -  executableExtension.size(),
> -  coverageExtension
> -);
> +coverageFileName.append( "." + coverageExtension );
>
>  if (!FileIsReadable( coverageFileName.c_str() )) {
>std::cerr << "warning: Unable to read coverage file: " <<
> coverageFileName
> --
> 2.7.4
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 14 May 2018 at 12:10, Cillian O'Donnell  wrote:

>
>
> On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, 
> wrote:
>
>> On 14 May 2018 at 02:15, Cillian O'Donnell  wrote:
>>
>>> ---
>>>  tester/covoar/covoar.cc | 10 +++---
>>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
>>> index 5c87402..c6b0589 100644
>>> --- a/tester/covoar/covoar.cc
>>> +++ b/tester/covoar/covoar.cc
>>> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
>>> executablesToAnalyze,
>>>  if (buildPrefix.empty()) {
>>>buildPrefix = *pri;
>>>  } else {
>>> -  if (buildBSP != *pri) {
>>> +  if (buildPrefix != *pri) {
>>>  fail = "executable build prefix does not match: " +
>>> buildPrefix;
>>>  break;
>>>}
>>> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
>>> executablesToAnalyze,
>>>  if (buildPath.empty()) {
>>>buildPath = thisBuildPath;
>>>  } else {
>>> -  if (buildBSP != *pri) {
>>> +  if (buildPath != thisBuildPath) {
>>>  fail = "executable build path does not match: " + buildPath;
>>>}
>>>  }
>>> @@ -316,11 +316,7 @@ int main(
>>>  std::cerr << "warning: Unable to read executable: " << argv[i]
>>> << std::endl;
>>>} else {
>>>  coverageFileName = argv[i];
>>> -coverageFileName.replace(
>>> -  coverageFileName.length() - executableExtension.size(),
>>> -  executableExtension.size(),
>>> -  coverageExtension
>>> -);
>>> +coverageFileName.append( "." + coverageExtension );
>>>
>>>  if (!FileIsReadable( coverageFileName.c_str() )) {
>>>std::cerr << "warning: Unable to read coverage file: " <<
>>> coverageFileName
>>> --
>>> 2.7.4
>>>
>>> This worked !
>>
>
> Cool, looks like we're onto fixing the reports then. If you take a look at
> report.html only the headings are there. I think what might be wrong there
> is it's just searching in the wrong place for the results. The fix for that
> will lie in coverage.py. Warning about coverage.py, there could be whole
> sections in there that might just be deleted, it's still being reorganized.
>
> Are you working on it ?
Also the absolute path needs to be parsed form the score-symbol.ini for
running it from out of the build tree

> Or seeing as covoar is in good shape now and I think the txt report is ok
> (you should check and make sure of that). You could move onto gcov, lcov
> stuff. Figure out the state of the gcov support in covoar, generate gcov
> reports, compare the results.
>
I'll creat a new thread for gcov report then.

> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, 
wrote:

> On 14 May 2018 at 02:15, Cillian O'Donnell  wrote:
>
>> ---
>>  tester/covoar/covoar.cc | 10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
>> index 5c87402..c6b0589 100644
>> --- a/tester/covoar/covoar.cc
>> +++ b/tester/covoar/covoar.cc
>> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPrefix.empty()) {
>>buildPrefix = *pri;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPrefix != *pri) {
>>  fail = "executable build prefix does not match: " +
>> buildPrefix;
>>  break;
>>}
>> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPath.empty()) {
>>buildPath = thisBuildPath;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPath != thisBuildPath) {
>>  fail = "executable build path does not match: " + buildPath;
>>}
>>  }
>> @@ -316,11 +316,7 @@ int main(
>>  std::cerr << "warning: Unable to read executable: " << argv[i]
>> << std::endl;
>>} else {
>>  coverageFileName = argv[i];
>> -coverageFileName.replace(
>> -  coverageFileName.length() - executableExtension.size(),
>> -  executableExtension.size(),
>> -  coverageExtension
>> -);
>> +coverageFileName.append( "." + coverageExtension );
>>
>>  if (!FileIsReadable( coverageFileName.c_str() )) {
>>std::cerr << "warning: Unable to read coverage file: " <<
>> coverageFileName
>> --
>> 2.7.4
>>
>> This worked !
>

Cool, looks like we're onto fixing the reports then. If you take a look at
report.html only the headings are there. I think what might be wrong there
is it's just searching in the wrong place for the results. The fix for that
will lie in coverage.py. Warning about coverage.py, there could be whole
sections in there that might just be deleted, it's still being reorganized.

Or seeing as covoar is in good shape now and I think the txt report is ok
(you should check and make sure of that). You could move onto gcov, lcov
stuff. Figure out the state of the gcov support in covoar, generate gcov
reports, compare the results.

> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Vijay Kumar Banerjee]

On 14 May 2018 at 02:15, Cillian O'Donnell  wrote:

> ---
>  tester/covoar/covoar.cc | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
> index 5c87402..c6b0589 100644
> --- a/tester/covoar/covoar.cc
> +++ b/tester/covoar/covoar.cc
> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPrefix.empty()) {
>buildPrefix = *pri;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPrefix != *pri) {
>  fail = "executable build prefix does not match: " +
> buildPrefix;
>  break;
>}
> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
> executablesToAnalyze,
>  if (buildPath.empty()) {
>buildPath = thisBuildPath;
>  } else {
> -  if (buildBSP != *pri) {
> +  if (buildPath != thisBuildPath) {
>  fail = "executable build path does not match: " + buildPath;
>}
>  }
> @@ -316,11 +316,7 @@ int main(
>  std::cerr << "warning: Unable to read executable: " << argv[i] <<
> std::endl;
>} else {
>  coverageFileName = argv[i];
> -coverageFileName.replace(
> -  coverageFileName.length() - executableExtension.size(),
> -  executableExtension.size(),
> -  coverageExtension
> -);
> +coverageFileName.append( "." + coverageExtension );
>
>  if (!FileIsReadable( coverageFileName.c_str() )) {
>std::cerr << "warning: Unable to read coverage file: " <<
> coverageFileName
> --
> 2.7.4
>
> This worked !

> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel