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 <j...@rtems.org> 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 <j...@rtems.org> 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 <cpodonne...@gmail.com>
>>>> 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 <cpodonne...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, <cpodonne...@gmail.com>
>>>>>>> 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 <cpodonne...@gmail.com>
>>>>>>>>> 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:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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 sure if we're still grabbing the objdump using rtems-tools
>>>>>>>>
>>>>>>> can't run sparc-objdump.
>>>>>>
>>>>>
>>>>> That might not be the exact name. Is there something that looks like
>>>>> it in that directory.
>>>>>
>>>>>> 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 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 is different in that it's just allowing the user an easier way
>>>>>>>> of choosing the right ini. So it wouldn't be a dependency like the
>>>>>>>> other
>>>>>>>> thing, if you run it manually you will still have to select the ini you
>>>>>>>> want. So this will be part of the script.
>>>>>>>>
>>>>>>> Oh , I will look into this then. :)
>>>>>>
>>>>>>> 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
