On Mon, May 21, 2018, 7:44 PM Chris Johns <chr...@rtems.org> wrote: > On 22/5/18 9:12 am, Joel Sherrill wrote: > > > > Attached is a shell script (pokes Chris) which calculates the size of > > the specified symbol across a set of .exe files. > > > > [joel@rtbf64c samples]$ /tmp/cmp_sizes -a sparc -s > > _Workspace_Allocate_or_fatal_error *.exe > > Size report for _Workspace_Allocate_or_fatal_error > > base_sp.exe - 0x4000c5a0 - 0x4000c5e0 (64) > > capture.exe - 0x400162a0 - 0x400162dc (60) > > cdtest.exe - 0x4001e6c4 - 0x4001e700 (60) > > cxx_iostream.exe - 0x4005cbdc - 0x4005cc20 (68) > > fileio.exe - 0x40020720 - 0x4002075c (60) > > hello.exe - 0x4000ac50 - 0x4000aca0 (80) > > minimum.exe - 0x40006240 - 0x40006280 (64) > > nsecs.exe - 0x4000c668 - 0x4000c6c0 (88) > > paranoia.exe - 0x4001426c - 0x400142c0 (84) > > ticker.exe - 0x4000d328 - 0x4000d380 (88) > > unlimited.exe - 0x4000cc0c - 0x4000cc60 (84) > > > > NOTE: Each SPARC instruction is ALWAYS 4 bytes. That will be > > important as we look at instruction addresses. > > > > I objdump'ed (sparc-rtems5-objdump -S) each exe as I got to it in > > the analysis. ( sparc-rtems5-objdump -S XXX.exe >XXX.dmp) > > The following is not something for the GSoC tasks and I report them here > and now > so we can keep them in mind. > > Binutils' objdump like addr2line uses the DWARF information held in the ELF > file. My close inspection of the DWARF data in the exe files we are > creating > leave me with some concerns. >
These are important to look into but should almost certainly not have anything to do with the bugs I described. Do they appear on other architectures? We.need to.move these questions to the binutils list? Only they can answer these. > > Specifically: > > $ sparc-rtems5-readelf --debug-dump \ > sparc-rtems5/c/erc32/testsuites/samples/cdtest.exe > /dev/null > > generates 3247 warnings of ... > > readelf: Warning: There is a hole [0x41f86 - 0x41f9c] in .debug_loc > section. > > I have not tracked down what this means. The elftoolchain's libdwarf does > not > report such issues however it is not parsing all the debug info data so > may not > be seeing it. > > I am seeing 583 instances of "Extended opcode 2: set Address to 0x0" using: > > $ sparc-rtems5-readelf --debug-dump \ > sparc-rtems5/c/erc32/testsuites/samples/cdtest.exe 2>&1 | \ > grep "Extended opcode 2: set Address to 0x0" > > If you grep for just "Extended opcode 2: set Address to" you will see the > address being correctly set in the line info DWARF program sequence for > most > entries however the setting to 0x0 seems wrong to me as the DWARF v5 > standard > section "6.2.5 The Line Number Program" states for line number info: > > Within a sequence, addresses and operation pointers may only increase. > > The output from above shows the line address being set to 0 after being > set to a > non-zero value. > > I do not know if these issues are specific to the SPARC architecture or an > option we use like section text and data. > > It is difficult to judge what effect these issues have on the coverage > analysis. > I feel we need this data to be accurate in-order to trust the results our > coverage tool creates. > > I need to look into binutils to see how this is being handled and if this > is > normal and expected behavior. > > chr...@rtems.org
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
